With right naming writing and reading code is much easier. The right — logical — convention also helps a programmer to come up with appropriate name, because a language designer already anticipated given case.
I don’t have a personal favorite way of writing code, I came from C++ world with underscores and I adapted to C# PascalCase smoothly — I want to make Skila naming great, considering what we already know about Java, C#, modern IDEs, and so on.
Types
PascalCase — for example “HashSet”.
Constants
PascalCase too. This includes enum elements (because they are constant values). The immutable objects are not considered here a real constant:
def Pi Double = 3.14; // true constant const obj = new Foo(); // immutable instance
Interfaces
No “I” at the beginning (like in Java). So far I recognize few issues with this approach:
- in favor — if you change the interface into an abstract class you don’t have to change its name (or the file name),
- disadvantage — it is easy to run out of the good names,
- another one — “I” takes little space and yet it helps a lot when reading or writing the code to differentiate between just an interface and real class.
Template parameters
All uppercase with underscores, like “TREE_NODE”.
Function parameters
camelCase.
Local variables
All lower case with underscore as separator — you cannot beat the speed of typing it, and unlike parameters they are not part of the API (i.e. they don’t have to look nice).
Non-private type members
camelCase — like “getCount”. I don’t like loosing upper case letter but the fact is — with short names it is quicker to type the code by yourself, not using IntelliSense, and then every Shift keystroke slows you down — the most apparent case is a member with just single word, like “count”, “map”. In such case typing feels more like flying over the words.
On the other hand I like the separation on public and non-public members by the case — PascalCase for the former, and camelCase for the latter.
Private type members
camelCase prefixed with underscore. The major reason is scenario like the one presented below (C# syntax):
private int _height;
public int height
{
get { return _height; }
set { _height = value; }
}
Since the name should reflect the meaning, the core name has to be the same — of the property and its backing up field. Not having mentioned before PascalCase and camelCase duality the other approach is to add underscore. And since you sometimes have to prefix private field with underscore, do it always.
I would be grateful for your critique or links to good insights on this subject (not easy to find because of all heated opinions), StackExchange usually kills any discussion but this one survived — Are there established alternatives to ISomething / ISomethingable for interfaces?.
Skila 