|
I just don't get these other replies. Future maintenance? What your boss thinks? Bahh!!!! Personally, I name all my variables and functions with 'l' and '1':
l, ll, l1, ll1, l1l, l11, llll, lll1, (and so on...)
I mean, take a look at the beauty of the following code:
<br />
for(ll1ll1l=l11llll; ll1ll1l=l111lll; ++ll1ll1l)<br />
{<br />
ll1ll1l1[ll1ll1l].ll1l1l();<br />
}<br />
|
|
|
|
|
Very handy dont you think? 
If I was your boss and you would make code like that, you would be fired the next day. This will cost a lot of money to maintain and if you wait to long to fix code like this, you will spend even more money to fix it...
WM.
What about weapons of mass-construction?
|
|
|
|
|
 I can't believe anyone actually believes I or thrakazog is serious.  (At least I hope thrakazog isn't serious or he will have a hard time keeping a job.)
Obviously such code will get you fired in a heartbeat (should someone review it that is).
Here's a more subtle approach which will probably eventually get you fired, just not right away: How to Write Unmaintainable Code[^]
|
|
|
|
|
Yeah, you're right. Sense of humor seems to be rare around here. Can't believe most didn't get the jokes.
|
|
|
|
|
that's why emoticons exist... to express one's feeling 
-- TTD --
|
|
|
|
|
I use a mixture of them for all my code.
Properties and methods use Pascal Casing...
Text
GetDisplayText
All internal variables use camel case...
customerCount
numberOfCalls
All private variables that pertain directly to the values accessible via a property or method are camel cased versions of the property...
text
getDisplayText
Any local variable that has module level scope (ie: vars global to a class) use are camel case with a leading 'm'...
mText
mNumberOfCalls
All GUI elements are camel cased with the prefix providing the control type...
txtUserName
chkSlection
cmbOptionDropdown
Constants are all upper case with an underscore separating the words...
THIS_IS_A_CONSTANT
My Blog[^]
FFRF[^]
-- modified at 11:15 Monday 3rd April, 2006
|
|
|
|
|
uncanny 
that is pretty much exactly how I do my variables
/jason
|
|
|
|
|
The question is about local variables only. 
Ray Cassick wrote: Constants are all upper case with an underscore separating the words...
THIS_IS_A_CONSTANT
That looks too Java-ish to me
Regards
Thomas
Disclaimer:
Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
