What single characteristic is most important for a good routine?

Question

Routines, procedures, methods - whatever you call them, they are important building blocks for us developers. What single characteristic would you rate as the most important one?

(By providing one characteristic per answer, it is possible to vote for them individually. I.e. the purpose of this question is not to decide single out one characteristic, but rather, to highlight all of the important ones.)

Answer 1

It has to be atomic

Answer 2

Lines of code.

Answer 3

Self Commenting Procedure Names.

Examples: GetStoreFromAddress GetCarsByMake

Answer 4

I think the most important criteria would be that it has a single purpose.

After that, that it satisfies that purpose (and only that purpose) correctly.

Answer 5

It should be easily unit tested.

Answer 6

designed to be easily read and understood by humans - without that in place it is much harder to modify it to have all of the other wonderful attributes that will be listed here

Answer 7

Number of things it tries to do.

If this isn't exactly 1 then you probably have a problem.

Answer 8

The routine's name maps one to one to it's functionality.

It's surprising how often a function X does X and also Y, or most of X but not all of X.

Answer 9

You should track the number of edits required after the routine was put into use. A 'good' routine is one with few edits required. A 'bad' routine definitely proves itself to be so when there are a bunch of fixes required.

This can easily be accomplished with a comment header on each method call that gets updated after each edit.

Answer 10

good error handling (reliability)

Answer 11

It does one thing or delegates multiple things to other functions

Answer 12

Clarity - Easy to understand

Answer 13

I think this is more easily answered if you consider routines as part of an API. There aren't many routines that stand alone, at least not in a truly useful system. So honestly, I think the most important things to consider when writing routines are:

1. Intuitiveness How intuitive is my set of instructions -- will people understand the purpose without having to wade through a lot of documentation?

2. Orthogonality How orthogonal are my routines? Does each accomplish one particular task, or are there multiple (but slightly different) ways to do the same thing? If there are, this is bad, and the API probably needs to be redesigned.

3. Compactness How much of the API does it take to get simple tasks done? Do I need to learn a lot of stuff to get something done, or can I suffice with just a couple routines that do something intuitive and powerful? You need to weigh the tradeoffs of this one with orthogonality to strike a good balance for your particular domain.

Answer 14

From the routine name, you can say what the routine does (and when you check the code, you realize that you were right ;-)

Answer 15

There is no single criterion that distinguishes a good routine from a bad one.

Among the criteria are:

• conceptual integrity: it does something that can be described in a simple short form, one sentence or paragraph;
• loose coupling: its behavior is not sensitive to what goes on in code around it;
• reasonable size: long routines are harder to read and understand, and are less likely to have good conceptual integrity;
• Parnas's criterion: they "hide" one thing that can change, so that requirements changes have limited effect on the rest of the system.

Answer 16

The routine uses a consistent level of abstraction throughout.

Answer 17

It shouldn't have unexpected side-effects.

Answer 18

I would say well documented (and actually enforced) pre and post conditions.

Answer 19

brevity

(this was supposed to be a semi-fun answer, but SO wouldn't let be post the single word on its own!)

Answer 20

A single return point