views:

93

answers:

6

One of my project's coding guideline is

"function/variable/parameter" name should be less than or equal to 31 characters.

The project is in C++.

IMHO this guide line is not useful because a) C++ compiler itself creates long names ( via name mangling).

b) Makes it hard to write self-documenting / expressive code.

What say ya??

+2  A: 

a) C++ compiler itself creates long names ( via name mangling).

Mangled long names are not something a developer normally has to see long confusing names you create are. So I consider this point irrelevant.

31 is a bit of an arbitrary limit but it still makes sense, sort of, to stop people creating crazy named variables. There are cases where longer names are sensible... but if you're trying to discuss code over the phone or something you will perhaps change your stance on them being expressive!

John
But then, even short named variables can be "crazy". I like expressive names e.g. like you see in Apple's MACOS's/Iphone's UI kit.
hotadvice
Thankfully i haven't seen names that exceeded 31 chars in Apples APIs... for whole sentences use comments or the developer documentation.
Georg Fritzsche
but "CGContextReplacePathWithStrokedPath" or "CGContextReplacePathWithStrokedPath" or "CGContextGetUserSpaceToDeviceSpaceTransform" are >31.These are not confusing but are self explanatory.
hotadvice
That's what namespaces/static classes are for, to collect similar functions together without having such insanely long names.
Blindy
Even with CGContext as a class/namespace, I would prefer "GetUserSpaceToDeviceSpaceTransform"(>31) for the function name. Isn't it expressive?
hotadvice
I assume the 31-limit is simply a rough attempt to keep naming sensible, obviously it's not perfect.
John
GetUserSpaceToDeviceSpaceTransform: GetUserToDeviceTransform or GetUserToDeviceSpaceTransform are as good in my eyes, especially if you comment the method appropriately.
John
+2  A: 

My answer is that of a 'balance'. Not matter how long or short function names are, they have to be intuitive and understandable. ProcessUpkeepAndDisptatchReports() is bad, and so is just Process().

Extrakun
A: 

It sounds a bit arbitrary. As I see it, the only reasoning for something like that to make it to the code standard means someone somewhere is taking a shortcut to teaching developers how to properly name stuff.

However, 31 characters should be more than enough to create a reasonable self-explaining variable. Even so, the only time I've seen obscenely long variable names was when a particular junior developer was trying to adhere too closely to "what it says is what it does" rule.

laura
A: 

About this I think the response lies in the oo design of your application ... as your classes as well designed you should have methods as open, close, read, write and so on ... also method have to implement a single task .... so don't write methods such as dothisandalsodothat()...

In my opinion longnames means wrong code , and 31 chars are even too much

luca
+1  A: 

I suspect that this rule is leftover from some older C/C++ programming guidelines. Some early compilers used a limited number of characters to distinguish names, so in some compliers myVariable1 and myVariable2 would be the same variable as the compiler might only consider the first 8 characters. If you look at borland Turbo C you will see that 32 is the limit!

You need to look at the documentaion for the current complier to see if this limit still makes sense and then consider the other points that other posters have made.

Jackson
A: 

a) Don't worry about compiler-generated mangled names (unless your compiler is seriously dysfunctional and imposes an unreasonable limit on them). They have no effect on the source code, which is what coding guidelines are concerned with.

b) Use classes and namespaces sensibly. Make each name short, stating its purpose in the context of its surrounding scope, and the fully-qualified name will document its purpose in the grand scheme of things.

c) Remember it's a guideline not a rule, and in some circumstances it might be necessary to use your brain. I suggest that a limit of "2 or 3 words" would make more sense than an arbitrary number of characters.

Mike Seymour