|
Thomas Freudenberg wrote: That looks too Java-ish to me
Id rather have that instead of what I have seen other people do.
I had to wade through code where all the constants where prefixed with just a C. I was going nuts at first thinking that they were classes instead of constants 
Ccustomertype
Cthis
Cthat
UGH!
My Blog[^]
FFRF[^]
|
|
|
|
|
An issue I'm having in this hippy-free-loving-no-Hungarian-notation world we live in is: how do you, syntactically, differentiate between locals and parameters? I'm talking .NET here, where parameters should be camelCased, fields Pascal cased, and class member variables prefixed with an underscore.
I used to use Hungarian for locals and camelCase for parameters, making it easy. But it was onconsistent since class members weren't getting the Hungarian treatment. I moved to PascalCase but then you've got that whole "is it a field or a local" thing.
Maybe I should just install Visual Assist X...
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Chris Maunder wrote:
Maybe I should just install Visual Assist X
Yeah, mine are purple, thanks to Resharper
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 find that unlike with class-level variables, I usually don't need to syntactically differentiate between locals and parameters. They're all scoped to the method anyway, and I try to decompose my methods enough that I don't have a huge number of variables to keep track of in the first place. In those rare instances where I really do need to know what kind of variable it is, I just refer to the method signature.
Any naming scheme is about finding the right balance between giving the human reader of code hints where they need them most, and not unnecessarily slowing down the writing of code. For me, starting class variables with an underscore, local variables without an underscore, using pascal case for methods and properties, and camel case for variables is just enough.
|
|
|
|
|
I agree.
Kevin
|
|
|
|
|
majahanson311 wrote: I find that unlike with class-level variables, I usually don't need to syntactically differentiate between locals and parameters.
True, that.
|
|
|
|
|
why would you like to differentiate the variables defined locally to a function, and the parameters that function receives ?
from a compiler view (i talk from a C/C++ point of view as i don't know other compilers well enough), parameters are local variables... you can use them just as you do with local variables, such as read them, modify them...
their existance is limited to the scope of the function.
|
|
|
|
|
I have used a veriaty number of naming convensions. Normaly I use the camelCase as I do not want to counfuse variable names with function names. I normaly use upper case for the first letter of a function name. If a need to destinguish a parameter from a local variable, for any reason, then I prefix it with "arg" or "par", but that is usually not required.
Lately I have been developing templates and have adopted the style used in the STL. The reason for doing that is so people who are use to looking at STL, will immediatly recognize it. The only difference is that I tend to use longer names inorder to make it clearer as to what is happening.
INTP
Every thing is relative...
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
