|
My group's conventions:
UPPER_CASE_WITH_UNDERSCORES: #define's, which are used for conditional compilation only.
PascalCase: Class names and public members. Underscores are used within the name only if the name includes an acronym that is all upper case (ex: ReadIJPDS_Message).
_PascalCase: Leading underscore indicates a private member.
camelCase or lower_case_with_underscores: Local variables and method arguments. This was one we elected to 'agree to disagree' on. Some of us like the camelCase one, others the lower_case one.
We have found that this set of loose conventions is sufficient that we can read each other's code. We don't bother with brace-style or white space conventions, as we found they were causing more annoyance than they were solving problems.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: _PascalCase
For C/C++ code? I thought that using an underscore as the first character was going against the C standard?? I might be wrong, but I'm sure that's "naughty". 
|
|
|
|
|
IIRC, the standard requires that compiler-specific entities use at least one leading underscore. While there is a potential conflict there, we've not encountered anything significant in actual practice. For us, it ranks in the same category as trying to establish a naming convention that doesn't conflict with the Win32 API; you simply can't do it.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: We don't bother with brace-style or white space conventions, as we found they were causing more annoyance than they were solving problems.
 don't even get me started on that!!
if (brackets_are_like_this) {
shudder();
}
c'mon, pixels aren't _that_ expensive!
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
Ah, K&R braces. The way God intended them to be.
Software Zen: delete this;
|
|
|
|
|
I usually prefice my private members with a "m_" as in m_iCountofThings .. don't know why, just always did it that way.. I think I saw it in a code sample, and used it ever since.
|
|
|
|
|
The m_ prefix is something that the Visual C++ wizards have generated since the 1.52 days and Windows 3.1 apps.
Software Zen: delete this;
|
|
|
|
|
I have to say, that the "camel Cased" method drives me insane. (I'd never heard it called that, btw.) What's the point? I think it looks silly, and doesn't convey any useful information other than, umm, it's a variable.
This has bugged me ever since a coworker started infecting my codebase with it. Thanks for the opportunity to rant.
|
|
|
|
|
David Kentley wrote: What's the point?
It's different from Pascal cased, so you dont have to think of variable names in circumstances that don't require it.
<br />
<br />
public void Stuff()<br />
{<br />
ThingAmiBob thingAmiBob = new ThingAmiBob();<br />
}<br />
<br />
Is better in my opinion than
<br />
<br />
public void Stuff()<br />
{<br />
ThingAmiBob MyThingAmiBob = new ThingAmiBob();<br />
}<br />
<br />
You can easily tell instance from type by the casing, without having to add prefixes or think up potentialy confusing names.
Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven."
- Penn Jillette
|
|
|
|
|
I will shoot on sight anyone who uses case sensitivity so that they can have symbols that vary only by case. Case sensitivity was a bad idea in the first place.
*shudder*
|
|
|
|
|
LeTs hopE we NEvEr MeEt, iT wOulD bE DagGeRS DRaWn :P
Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven."
- Penn Jillette
|
|
|
|
|
Ryan Roberts wrote: LeTs hopE we NEvEr MeEt, iT wOulD bE DagGeRS DRaWn
No doubt. However, please note, that if the english language was case sensitive like C is, the above sentence may very well be translated as, "Let's eat mashed potatoes with rabid chickens." See what a mess case sensitivity is?
|
|
|
|
|
Camel casing is the way to go. Its primary function is to create a variable name from concatenated words and still be easy to read.
Who wants type info or.. scope (wtf is that scope crap?!!? who does that!?) all over the code. Nasty business that, it's just fluff that your brain has to process before you get to useful part, the name of the variable. While it may be very dubiously useful in a typeless language it's still just filling up the screen with fluff. The type of the variable should be implied implicitly because of how it is used. I dont have any trouble reading it (it is the MS standard - see dotnet naming convention doc).
On the subject of case sensitivity. It's a good thing, not because it allows you to have two variables with the same name differing only be case (though that is cool, why? read on) but because anyone who uses that member will all call it in a consistent way.
There'll be no:
foo.Hello() - Bobs code
foo.hello() - Sally's code
foo.HeLLO() - Some idiots code
Cause the compiler will force Bob, Sally and the idiot to all write foo.Hello().
A benefit of being able to have variables with the same name differing by case only is best demonstrated with the field property example.
long customerId;
public long CustomerId{
get{ return customerId; }
}
Users of the API only ever see one member (CustomerId). Meanwhile your not forced into a situation where u have to use stupid prefixes like m_. Now because ur using a case sensitive language and u've used camelCasing u know what customerId is for because it starts with a lower case letter. And u know what CustomerId is for because it starts with an uppercase letter. And the relationship between the two is obvious because they have (almost) the exactly same name.
I like the naming convention used by MS in the dotnet framework. A lot of thought went in to it and it's consistently often allows me to guess the names of things without ever needing to go looking stuff up. If chaos is your preferred environment, keep using vbscript or some trash.
Someone needs to send these VB programmers to skool!
Note: Year i'm aware i'm using a mixture of Pascal and camel. My rule of thumb is camel for local vars, parameter arg names etc. Public properties, methods, class names interface names etc all get Pascal casing.
[worldspawn]
-- modified at 3:17 Tuesday 4th April, 2006
|
|
|
|
|
worldspawn wrote: your not forced into a situation where u have to use stupid prefixes like m_.
I'm sorry for beeing a bit.... aggressive? but that line takes the price.
How stooooopid can you get?
Please dont tell me you omit the prefix for any global variables?
I've been cleaning up code that has been written by a total of 4 developers and a bunch of outsourced programmers and it took me a bloody month just to figure out what was local, member and global variables and that was time I just as easily could have spent on something more useful than trying to decode other jerks code.
worldspawn wrote: Someone needs to send these VB programmers to skool!
I'm not a VB-programmer, but stay clear of that subject.
I shared your opinion in the beginning of my career but nowadays I do have a job and far too much to do rather than flaming someone for the language they use....
Sorry for biting your head off but I just had to get this out of my system
Ciao
|
|
|
|
|
Thankfully I dont develop in an environment that has "global variables". Nasty business those.
How can it take you a month to determine the scope of a variable? The variables location in code implies it's scope. I look at code I write and if a variables called "eatPizza" i know it's a local/member variable because of how it's been cased... casing aside, whats more obvious is where its defined in a class. 
Subject crashed in to. The language isn't really bad, it's just that VB programmers have an alarming tendency to write badly constructed code. I know I've read a lot of it.
I dunno what language u code in, i write dotnet apps in c#. And i follow the microsoft naming guidelines. Why? Cause then my code is written in the same manner as the framework.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp[^]
[worldspawn]
-- modified at 19:41 Tuesday 4th April, 2006
|
|
|
|
|
worldspawn wrote: Thankfully I dont develop in an environment that has "global variables". Nasty business those
Global variables are the worst nightmare you can run into.
worldspawn wrote: How can it take you a month to determine...
It took me a month to parse out the entire Gb+ of source-code.
Since it was several developers, with just as many different styles, with absolutely no notation at all, a variable named bStuff could be local, member or global and since I was thrown into this project in the end, more or less to clean it up because of the problems we have, well,... there are some guys hwo are not going to recieve any xmax cards
worldspawn wrote: I dunno what language u code in
I'm coding in C++
Anyhow, That's part of the history and I've made a promise to myself that I will resign before I do anything like it again
Cheers
|
|
|
|
|
Apart from some offensive-language details, I can sign this post.
Hungarian notation can die, because the way something is used and the UI can tell you exactly the type of a variable. I used it until recently for UI controls, but now I've changed txtxxxx to something like
xxxTextBox - and this because i can have a xxx variable and a xxx text box at the same time.
In this way autocomplete works waaay better, when I write xx I have already the 1-3 things related to the task at hand (I am occupied with xxx and I know it) and not ALL the text boxes of the class (:S). Yes, I know this notation is longer, but, well, I write the whole variable name exactly once, the other times autocomplete does it for me. My advice: learn to live with autocomplete.
Combining pascal and camel notation to distinguish between Properties and private variables works quite nice: the client sees consistently MyObject.Something when he wants to use a variable, and in your code you almost always write something for variables and Something for functions. It is very easy to get used to and you can understand very well what's happening. In the rare case that you accidentally write Something for a local variable, the compiler will easily optimize it. You haven't really done something wrong, just in some cases added some extra validity checks (sometimes you want to do it). So no harm can be done here.
Distinguishing between local variables and class variables has no good use IMO. A function has to be short, its variable declarations close to its use and it will be evident what's local and what's not (and most of the time, it just doesn't matter). Even if not, the variables will have good names. In the rare case that the names are not enough, write /// (in C#) comments over them and when you point the mouse over them, everything's clear. You should NEVER have to backtrack to the top of the file to see the variable declaration to understand what happens in a well written code.
So, to sum up: use camel notation and clear, evident names. Use camel notation to have all the useful information in the first letters of the variable. Autocomplete is your friend. The result will be a code easy to be read. If you have to correct someone's code which is not as clear the solution is to learn him to write evident names and not to use a convention that will slow down his productivity (hungarian notation=more keystrokes every time a variable is used which is always worst than more keystrokes only in the variable's declaration).
-- modified at 5:56 Tuesday 4th April, 2006
|
|
|
|
|
David Kentley wrote: Case sensitivity was a bad idea in the first place.
Yes it was. But in the fairly dominant C-family languages in use it has become widespread so we have to adjust to it.
Kevin
|
|
|
|
|
You're a VB coder ain't you ? 
|
|
|
|
|
David Kentley wrote: ForumSurvey: Coding style: How do you name your local variables?
Subject:Re: Why camelCased?
Sender:David Kentley
Date:11:59 3 Apr '06
I will shoot on sight anyone who uses case sensitivity so that they can have symbols that vary only by case. Case sensitivity was a bad idea in the first place.
*shudder*
hey, can I join your one man army?
|
|
|
|
|
Case in point.
We have an enum type in one IDL file and an enum member in another IDL file, both with the same spelling. Each has different case, however.
Do you think the MIDL compiler can tell them apart - NOT 
Distinguishing a variable from a type purely onc ase has always been a very bad idea to me too 
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Blake Miller wrote: Distinguishing a variable from a type purely onc ase has always been a very bad idea to me too
I wouldn't do it in anything other than the scope of a method, where the context should be simple enough to differentiate using case alone. Providing everyone else is playing by the same rules in other scopes of course 
Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven."
- Penn Jillette
|
|
|
|
|
lol
the other day, parsing along the lines... ran into something funny...
2 separate modules, module A and B
A had a method called CmdDoSomethingCool and the other module had a const int named,..guess what... CmdDoSomethingCool.
Only problem, a file from module A was included in module B, and if not included in the right order, well... sometimes it would actually compile but crash in runtime and sometimes, it wouldnt even compile...
Those pricks (sorry 'bout that) who wrote the code should be deported to another planet!!!!!
That and code that reads something like:
*p = GetPointer()
if (NULL==p)
UsePointer(p)
I found those lines all over the place.... and then they wonder why the heck it crashes.... lol
I think the poor chap who wrote the code was a victim of Copy'N'Waste...
lol
|
|
|
|
|
Ryan Roberts wrote: It's different from Pascal cased, so you dont have to think of variable names in circumstances that don't require it.
public void Stuff()
{
ThingAmiBob thingAmiBob = new ThingAmiBob();
}
Is better in my opinion than
public void Stuff()
{
ThingAmiBob MyThingAmiBob = new ThingAmiBob();
}
I think it's generally considered bad style to have an instance variable name that differs from its type name only in case. A type name represents the name of... well, a type! When creating an instance of a type, the instance name should be specific enough to differentiate it from other instances of the same type, as well as from the type itself, for that matter.
There are times when it is tempting to break this rule. For example, say you are passing a timer to a method:
public void SomeMethod(Timer timer)
{
}
The context could be general enough till it becomes difficult to think up a name for the parameter that somehow distinquishes it from its type. The purpose of the method may give us a clue, though, and we could rename the parameter something like pollingTimer, or whatever. Sometimes its kinda tough, and you may wind up just naming the parameter t or tmr, if you want to strictly avoid having a variable name differ from its type name only in case. But that may not be any better.
So my question for everyone is what would you do in the above situation when it just isn't clear what a parameter should be named?
-- modified at 15:36 Tuesday 4th April, 2006
|
|
|
|
|
Leslie Sanford wrote: I think it's generally considered bad style to have an instance variable name that differs from its type name only in case. A type name represents the name of... well, a type!
Agreed, in most circumstances it is - but in others the typename is an obivous, easily understood choice. When a single instance of a class is required in a method, and that class has a descriptive name I don't see the point of naming it "myCustomer" or "theIndexer" or "aDirectory" or "tickyTimer".
Leslie Sanford wrote: So my question for everyone is what would you do in the above situation when it just isn't clear what a parameter should be named?
Camel cased typename , if further classfing the parameter is redundant - which it is in the Timer example. DoStuffWithTimer(Timer aTimerToDoStuffWith) is a tad pointless IMHO when the type is descriptive and distinct.
World isn't going to burn with either method though
Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven."
- Penn Jillette
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
