views:

248

answers:

6

Are the naming conventions similar in different languages? If not, what are the differences?

+1  A: 

Of course there are some common guidelines but there are also differences due to difference in language syntax\design.

For .NET (C#, VB, etc) I would recommend following resource:

aku
+4  A: 

Each language has a specific style. At least one. Each project adopts a specific style. At least, they should. This can sometimes be a different style to the canonical style your language uses - probably based on the dev leaders preferences.

Which style to use?

If your language ships with a good standard library, try to adopt the conventions in that library.

If your language has a canonical book (The C Programming language, The Camel Book, Programming Ruby etc.) use that.

Sometimes the language designers (C#, Java spring to mind) actually write a bunch of guidelines. Use those, especially if the community adopts them too.

If you use multiple languages remember to stay flexible and adjust your preferred coding style to the language you are using - when coding in Python use a different style to coding in C# etc.

Daren Thomas
+1  A: 

G'day,

One of the best recommendations I can make is to read the relevant section(s) of Steve McConnell's Code Complete (Amazon Link). He has an excellent discussion on naming techniques.

HTH

cheers,

Rob

Rob Wells
+1  A: 

I think that most naming conventions will vary but the developer, for example I name variables like: mulitwordVarName, however some of the dev I have worked with used something like mulitword_var_name or multiwordvarname or aj5g54ag or... I think it really depends on your preference.

Unkwntech
+2  A: 

As others have said, things vary a lot, but here's a rough overview of the most commonly used naming conventions in various languages:

lowercase, lowercase_with_underscores:

Commonly used for local variables and function names (typical C syntax).

UPPERCASE, UPPERCASE_WITH_UNDERSCORES:

Commonly used for constants and variables that never change. Some (older) languages like BASIC also have a convention for using all upper case for all variable names.

CamelCase, javaCamelCase:

Typically used for function names and variable names. Some use it only for functions and combine it with lowercase or lowercase_with_underscores for variables. When javaCamelCase is used, it's typically used both for functions and variables.

This syntax is also quite common for external APIs, since this is how the Win32 and Java APIs do it. (Even if a library uses a different convention internally they typically export with the (java)CamelCase syntax for function names.)

prefix_CamelCase, prefix_lowercase, prefix_lowercase_with_underscores:

Commonly used in languages that don't support namespaces (i.e. C). The prefix will usually denote the library or module to which the function or variable belongs. Usually reserved to global variables and global functions. Prefix can also be in UPPERCASE. Some conventions use lowercase prefix for internal functions and variables and UPPERCASE prefix for exported ones.

There are of course many other ways to name things, but most conventions are based on one of the ones mentioned above or a variety on those.

BTW: I forgot to mention Hungarian notation on purpose.

Anders Sandvig
ThisIsPascalCase, thisIsCamelCase. never heard of javaCamelCase
Matt Lacey
A: 

Years ago an wise old programmer taught me the evils of Hungarian notation, this was a real legacy system, Microsoft adopted it some what in the Windows SDK, and later in MFC. It was designed around loose typed languages like C, and not for strong typed languages like C++. At the time I was programming Windows 3.0 using Borland's Turbo Pascal 1.0 for Windows, which later became Delphi.

Anyway long story short at this time the team I was working on developed our own standards very simple and applicable to almost all languages, based on simple prefixes -

  • a - argument
  • l - local
  • m - member
  • g - global

The emphasis here is on scope, rely on the compiler to check type, all you need care about is scope, where the data lives. This has many advantages over nasty old Hungarian notation in that if you change the type of something via refactoring you don't have to search and replace all instances of it.

Nearly 16 years later I still promote the use of this practice, and have found it applicable to almost every language I have developed in.

titanae