Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am a huge fan of .NET Framework 1.1 Naming Guidelines available here.
Also I prefer to code using hungarian notation from Charles Simonyi.

What about you? Which naming guidelines do you follow in which programming language?

share|improve this question
7  
Which programming language? Naming guidelines differ from language to language... –  missingfaktor Oct 24 '10 at 6:17
add comment

11 Answers

up vote 20 down vote accepted

You should follow the lexical conventions of the file, subsystem, project, and language you're working in, in roughly that order of precedence. This will include things like the use of CamelCase versus underscores, conventional use of prefixes/suffixes, Hungarian notation (either Simonyi's original intent or the broken Systems Hungarian or neither), and so on and so on.

Once you're past the above (and that's what most people argue about), naming guidelines really boil down to effective communication: how do you make your code readable. Here are some thoughts that I have come to believe over the years.

  • Choose names that are understandable when read out loud. This means they should largely follow the phrase order of the (natural) language the team writing the software. (Many of the later suggestions in fact are special cases of this one.) For example, given an object type "foo", the function name allocate_foo is better than foo_allocate because the former is the more natural English phrase.

  • Name boolean variables, members, or functions in the postive sense. For example, prefer done to notFinished, empty to notFull, etc. The latter choices will lead to much more complicated expressions in conditional statements.

  • Name functions that test some condition in the form of a question: isDone, or hasSomeInterestingProperty, etc.

  • Name accessors with noun phrases, with adjectives as necessary. radius or backgroundColor and so on, and avoid useless prefixes on these like get or find.

  • Name update operations with verb phrases. So, sort or insert or insertAfter and so on.

  • Avoid vague names like handleFoo, except perhaps for things like state machine event handlers where there isn't really much else to say.

  • Avoid names that expose implementation internals. Don't write findThingOnSomeQueue if the reader has to look inside the function to see what a SomeQueue is, just say findThing.

One suggestion that is often in tension with those above, and yet I also believe is quite important: Don't be (too) verbose. Good notation is concise notation, and names are a form of notation.

  • Do use abbrevations for key concepts (whether in the user domain or in the implementation domain) but use them consistently.

  • Do use short local variable names, especially for conventional uses such as loop indices or iterators. Otherwise, local names need to be longer as the function gets longer. (If your local variable names start to get long, your function is too big.)

I suspect that this last set of thoughts is where I most differ from current conventional wisdom.

Finally, I would highly recommend reading Clean Code by Robert C. Martin. It's probably the best book I've ever read on the general issues of code and design tidiness (including naming conventions) at the level of the function, file, and subsystem.

share|improve this answer
    
I agree with most of these, except the first. If you have a number of functions which operate on a Foo, it's far better to have foo_allocate, foo_init, foo_destroy, etc, as it makes the functions easier to find in any list, and helps when using auto-complete. –  Steve Melnikoff Oct 27 '10 at 12:36
    
I can see your point, but here's an expanded example: given a module "foo" for handling Foo structs, I would write foo_allocate, but I'd do so because I'd tend to prefix all public functions from this module with "foo_". If "foo" was more of a service, with several sorts of things to allocate and destroy, I would still write those as foo_allocateThing1, foo_allocateThing2, and so on. If I was working in a OO-ish language, then "Foo" would be the namespace or class, and the methods wouldn't have the "foo_" prefix. –  Dale Hagglund Oct 30 '10 at 20:56
    
@SteveMelnikoff - Is "foo_" easier to search for than "_foo"? A strike against camel case and for underscores, perhaps! Anyway, this goes away in OO languages: "foo.allocate()" and in languages with overloading: "allocate(foo)". –  Kaz Dragon Oct 12 '11 at 15:31
1  
@KazDragon: yes, I'd suggest that "foo_" is easier to find in a list of functions, as provided by many IDEs - especially if the list is in alphabetical order. –  Steve Melnikoff Oct 12 '11 at 15:41
add comment

I think that Code Complete is a very good general book in naming stuff. It is also important that you take into consideration what language you are using.

share|improve this answer
    
Could you be more specific, like quoting parts of the book that can help on this specific topic to make your answer more thick and helpful? –  Matthieu Sep 14 '12 at 18:16
add comment

I work in C# and use CodeAnalysis (FxCop) and SourceAnalysis (StyleCop) to provide guidance for naming styles.

share|improve this answer
add comment

Following the style of the standard library for that language leads to nice-looking code. If you're in a language that does object.SomeMethod() or object.someMethod() or object.some_method() in its standard library and you follow that convention it will at least look professional.

Ultimately they're just identifiers that some compiled languages throw away anyway, so don't spend too much time deciding among someMethod, SomeMethod or some_method.

share|improve this answer
add comment

I follow whatever naming guidelines are published (or accepted) for the language I'm using:

In C# I use PascalCase for classes, methods, constants and enums, camelCase for variables, and _camelCase for private fields. I do not use Hungarian Notation. I use descriptive names.

In Java or PHP I would use PascalCase for classes, ALL_CAPS for constants, and camelCase for pretty much everything else.

In Ruby or Python I would use underscore_separated for variables and methods, ALL_CAPS for constants, and PascalCase for classes.

share|improve this answer
add comment

I tend to think people over complicate naming conventions. My rule is simple.

A variables name should convey the data it stores with emphasis on human readability.

That is my only rule and it has served me well over the years.

share|improve this answer
add comment

I use whatever ReSharper tells me to.

share|improve this answer
1  
also there's a FXCop from Microsoft, nice tips there. –  Junior Mayhé Oct 27 '10 at 16:54
add comment

A better question would be, what popular languages don't have clear style guides from authoritative sources?

I checked the google and found guides for Java, C#, ruby, python, php and c/c++ in less than a minute. Within php, there are pear and drupal guidelines.

I'm convinced that much of the debate on coding styles is about the desire of some programmers to have some say on what their teammates do.

share|improve this answer
    
"I'm convinced that much of the debate on coding styles is about the desire of some programmers to have some say on what their teammates do." That is so true in some shops. Extra points if you have subteams and little fiefdoms each with their own style (but that's a management failure and another topic). –  anon Oct 12 '11 at 23:34
add comment

In Elisp/Scheme/Common Lisp, I follow the naming conventions implicitly set out in Practical Common Lisp with a few changes, influenced by PLT Racket coding standards. All lower case, sub-words delimited by -, global variables wrapped by *, predicates end in ? and functions with side-effects end in !. Finally, functions that convert an input to an output get named with a -> to denote that.

For example (these aren't necessarily GOOD function names, I'm just using them to demonstrate the above standards)

sort           ;a functional sort (I expect it to return a new list)
merge-sort     ;a function with a longer name
*colors-list*  ;a global variable
starts-with?   ;a predicate (I would expect it to return NIL or the match)
sort!          ;a destructive sort (I expect it to return t or NIL and modify its inputs)
rgb->hsb       ;a function that takes an RGB color and returns an HSB color

These are all composeable, of course, so I could name a function hsb->rgb! (and I would expect that one to return t or NIL and modify the color I passed it from HSB to RGB representation). You can tell a surprising amount about what's going on in a given piece of code by paying attention to the naming conventions.

In other languages (which tend not to use prefix notation), I just stick to the standard camel-caps naming, but I do name any predicate functions with a trailing _p.

share|improve this answer
add comment

First: use whatever case convention is generally accepted for the language of choice, and

Second: the really important one, name classes, attributes and methods so you don´t need to write comments explaining them.

share|improve this answer
add comment

There needs to be a clear distinction between Hungarian notation as originally intended by Charles Simonyi and Systems Hungarian. Thanks to @Inaimathi for pointing to this article joelonsoftware.com/articles/Wrong.html. I admit that I was one of those who fell victim to this misunderstanding.

I don't think Systems Hungarian notation adds much value nowadays, when embedding data-type information in variable names. Linus Torvalds and Bjarne Stroustrup said it best:

Linus Torvalds:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmerthe programmer

Bjarne Stroustrup:

No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version > of a type in a variable name) a technique that can be useful in untyped languages, but is > completely unsuitable for a language that supports generic programming and object- oriented programming—both of which emphasize selection of operations based on the type an > arguments (known to the language or to the run-time support). In this case, 'building the > type of an object into names' simply complicates and minimizes abstraction.

I can see Hungarian notation being very valuable in UI programming where it is benefitial to know whether somethign is a text field or a label. For example, I usually do this: lblCustomerName (label preceding the text field), txtCustomerName (actual text field).

Also, whatever convention you chose, make sure the name is descriptive and does not need a comment line above variable declaration. It doesn't cost us anything to make a descriptive variable, method, or class name. In the end, the code will be more readable, which is important. Programmers spend more time reading code than writing it.

On a more technical side of things, below are some of the guidelines that I follow, which use Hungarian notation (I'm a .NET developer):

  • I use Camel casing.
  • 'm_' prefix for class variables
  • '_' prefix for method parameter declarations
  • 'I' prefix for interface names
  • 'Base' postfix for base classes
share|improve this answer
    
Read over joelonsoftware.com/articles/Wrong.html. Both quotes you cite above refer to the useless subset of Hungarian Notation publicized by various Microsoft docs. The original paper by Simonyi (which I assume NiceTShirts is referring to since he specifies "...hungarian notation from Charles Simonyi") encourages embedding information about the use and content of a variable in a prefix to its name (in the way that you name class variables "m_foo"), rather than data-type information. Ironically, three of the standards you say you use are Hungarian Notation in this sense. –  Inaimathi Oct 24 '10 at 5:35
    
@Inaimathi - Thanks for pointing that out. You are absolutely right and that is a very valuable article. I've edited my post accordingly. –  ysolik Oct 24 '10 at 6:16
2  
Joel's article is good, but doesn't go quite far enough. If you are working in a statically typed language, you can set the type system up so that thing's that are wrong not only look wrong, but won't compile. For example, you can write wrapper classes for unsafe strings, and change your database access layer to only accept safe strings as parameters. –  Larry Coleman Oct 24 '10 at 15:09
1  
@Larry Coleman I can't support this statement enough. Using a prefix in the front of your variables and functions is so vastly inferior to having the compiler enforce it for you, that I almost couldn't bring myself to put the two ideas in the same sentence together. –  flamingpenguin Oct 25 '10 at 15:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.