|
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
|
|
|
|
|
myTimer of course!
Todd Smith
|
|
|
|
|
So what do you use instead?
Kevin
|
|
|
|
|
David uses a random case selector to help exercise anyone who reads his codes brain.
[worldspawn]
|
|
|
|
|
my_local_variable
Sorry "underscore haters". It's a part of the coding standard for the group
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Often quicker to type too... I am leaning towards this style nowadays myself...
|
|
|
|
|
Robert Edward Caldecott wrote: I am leaning towards this style nowadays myself...
Well, it is the style of the Standard Library, so if you are using it a lot (we do at my work) it makes sense to adopt it. Back in the days I was using MFC more, Hungarian notation was a natural choice.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
:|Quick? I'll rather break my keybord that look for the bleeding ^shift key and the whatsitcalled_underscore
Cheers,
Rohit Wason
|
|
|
|
|
I have the same problem!
Kevin
|
|
|
|
|
Robert Edward Caldecott wrote: Often quicker to type too...
I disagree. I find it harder to type. However, from a readability point of view it is superior to Camel and Pascal case. It is also the Eiffel house style and if I ever get to do Eiffel I would fall in with it and probably get used to it too.
Kevin
|
|
|
|
|
|
The question was about "local" variables.
Not members, statics etc...
/cadi
24 hours is not enough
|
|
|
|
|
|
hmm.. you got point.
I thought local was meant to be method-body-local....
But how about assembly local and program local then... is a class local to it's assembly?
(just a joke...)
/cadi
24 hours is not enough
|
|
|
|
|
cadi wrote: But how about assembly local and program local then... is a class local to it's assembly?
(just a joke...)
Actually, it's a good question, and sort of points out the arbitrary qualities of coding styles. You say toehmahtoe, I say toemaytoe.
Marc
Pensieve
Functional Entanglement vs. Code Entanglement
Static Classes Make For Rigid Architectures
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
|
|
|
|
|
I meant local variables, as in "local variables to a routine", not "local fields to a class".
Everytime I write one of these polls I feel I should consult counsel to ensure I've covered everything. When polls start with "WHEREAS..." you know I've finally cracked.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
"Method variables" would have worked for me. I have to admint I misunderstood the poll as asking about "Class variables" (well actually, "fields" in C#).
Now that I know what the poll is asking, I have to say I'd fire anyone that didn't respond with camelCasing
|
|
|
|
|
Hmm. I still use the m_ prefix for dialog box DDX variables, as sort of a 'mini-convention' within a dialog class. It makes it easier to differentiate the variables that are used for 'dialog data exchange' from others.
Software Zen: delete this;
|
|
|
|
|
For locals? Or did you mean member vars? (I do that).
/ravi
My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com
|
|
|
|
|
I have been using Hungarian notation since I started programming for Windows 15 years ago. However, I sometimes experiment with different styles for code that no-one else needs to maintain. For example, I always use member Get/Set functions to access class variables, which are nearly always private, so, IMHO, as long as the member variable has a sensible name, there is a good argument for dispensing with Hungarian notation altogether. In some of my classes I have even switched from prefixing all my member variables with m_ to instead using a _ suffix, e.g.:
From:
std::wstring m_strName;
To:
std::wstring name_;
If someone else is going to use the class, ALL access to name_ is via methods. However, if someone else were to come along and maintain my code, then they might not like this naming convention. We have no rules for this here - it is up to the individual - and as many of the guys here are Unix programmers, where Hungarian notation is virtually unknown - forcing them to use it would be counter-productive.
Interestingly, I am doing a Java course at the moment, which tells you to use camel notation, but shys away from any Hungarian-style notation - again, it says you should just use a sensible name for the variable.
|
|
|
|
|
for simple loops i tend to use "int i", after all, it is traditional
i like hungarian when it helps
but when i reach fun things like:
std::list< std::pair< std::string, CLongClassName > >
or worse, i give up, and call it something sensible like: m_listDrugMapping
i hate having to move the mouse over a variable and waiting for the IDE to tell me what it is, and this does not work when editing the same code in a different editor on a different OS, so i do what ever helps, so long as it is not to much trouble.
zen is the art of being at one with the two'ness
|
|
|
|
|
feline_dracoform wrote: std::list< std::pair< std::string, CLongClassName > >
Personally, I wouldn't include the fact it is a "list" in the variable name - I sometimes change the container type (i.e. you might decide a vector is better at some point down the line), so I would tend to use cnt to indicate it is a STL container - then the implementation can be changed later without messing up the variable names.
|
|
|
|
|
interesting point. to be fair the code snippet is fake, since i use Qt 3. due to a massive lack of STL classes on our UNIX box i have to stick to the collection classes included with Qt 3. realistically i cannot change the collection type later on, since they tend not have compatible interfaces
zen is the art of being at one with the two'ness
|
|
|
|