|
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
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
