|
Dario Solera wrote:
I refuse to read things like MAX_REQUESTS or m_Val... MaxRequests and mVal are more more more clear!!!
really ??? 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Really!!!
I have to say that the IDEs help a lot, for example placing different icons for different data types, so the notation becomes less important to understand the code.
But I really hate underscores: they waste space and (in my opinion) don't make the code more readable.
[ITA] Tozzi ha ragione: Gaia si sta liberando di noi.
[ENG] Tozzi is right: Gaia is obliterating us.
|
|
|
|
|
i think you're making a problem of another thing...
underscores are not so unreadable. some people love, some support with difficulty, some "HATE", but i never heard someone that was refusing reading a word containning an underscore (you notice that i say underscore in plain text to allow you see what i write  ). you might not undertood much thing of what you read this way if you jump over every words containing a '_' (oops, sorry  )...
personnally, i find the m_var more useful than mVar because i see at reading it that it is a member of a class. for me (but it my convention maybe), when the first lower case letter is sticked to the identifier, it descibes the type of that identifier... mVar could represent a variable which type is a user defined one, such as a map, a matrix, and so on...
the most important is that you have your own rules, and follow them at the bottom of the letter...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Maybe I was too strong. Obviously if I have to read code written by someone and it contains stuff like m_var, I understaind it without problems. I don't *refuse* to read it!!!
Since ... I don't remember when ... I used some specific notation rules, that are comfortable to me. These rules came from my teachers, my manuals and my programming books, and fortunately I found almost always the same conventions. So, as a result, I never use underscores, and since I write only OO programs, ALL the variables are class members...
mVar was only an example. Usually I write vars like ... mousePos. I intend the first word as the data type only for UI vars, for example btnSend, frmLogin and so on...
In every case I use always the same notation.
I believe I'm a pretty good programmer regarding notations  ... or not?
[ITA] Tozzi ha ragione: Gaia si sta liberando di noi.
[ENG] Tozzi is right: Gaia is obliterating us.
|
|
|
|
|
Dario Solera wrote:
I believe I'm a pretty good programmer regarding notations ... or not?
maybe, but i cannot say, i never read code of your own.
Dario Solera wrote:
since I write only OO programs, ALL the variables are class members...
oh, and what happens to local variables ? 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
You're right but personally I like to use the same camelCase notation. Since no one, up to now, has slammed my habit, it means it is understandable.
In Italy we say: 'Le cattive abitudini sono dure a morire', that means: Bad habits die hard.
So, if you really believe I'm wrong, I say: can you tell what notation is the best? If the most people have a behavior, this does not mean that it is the best one. In both the cases.
And here comes the importance of code documentation...
[ITA] Tozzi ha ragione: Gaia si sta liberando di noi.
[ENG] Tozzi is right: Gaia is obliterating us.
|
|
|
|
|
Dario Solera wrote:
If you write in .NET, especially in C#, you should (I may say you must) use the Common Language Specifications. For example never use underscores in the var names, and use for them the camelCaseNotation.
No-no for (leading) underscores is because some languages don't support them. When you use _variables for private members, you are still CLS-safe  In this case it it really only personal preference. And since private variables are hidden, I prefer easiest way to make up their names. That is, underscore + name (of coresponding property usualy). That way I have no problem with this or property called Namespace (since namespace is keyword, and nameSpace is plain ugly). Hmm yes, I spend waaay tooo much time about this issue in past 
Never forget: "Stay kul and happy" (I.A.)
David's thoughts / dnhsoftware.org / MyHTMLTidy
|
|
|
|
|
Hmmmm...
Do you really need to use 'this' and 'namespace' as var names?
However we discussed about private variables names.
To make my thesis (see previous posts) more convincing, I suggest you to scan the MSDN Library: for C++ articles, the 'classical' C notation is used, for all the other languages, You may say that each author uses a different notation, but all of them converge to the camelCaseNotation for vars names and PascalNotation for classes, namespaces and public members names.
[ITA] Tozzi ha ragione: Gaia si sta liberando di noi.
[ENG] Tozzi is right: Gaia is obliterating us.
|
|
|
|
|
Dario Solera wrote:
Do you really need to use 'this' and 'namespace' as var names?
I didn't mean this as variable name, but as in this.var when you have argument of same name. How would you call varible representing namespace (e.g XML namespace)? ns, nameSpace, myNamespace, xmlNamespace (this is probably the best alternative,)? All long or ugly/nondescriptive IMHO. And yes I am talking about private variable names, too...
Dario Solera wrote:
To make my thesis (see previous posts) more convincing, I suggest you to scan the MSDN Library: for C++ articles, the 'classical' C notation is used, for all the other languages, You may say that each author uses a different notation, but all of them converge to the camelCaseNotation for vars names and PascalNotation for classes, namespaces and public members names.
And I suggest you to download Rotor and see that you can find _underscore, camelCase and even m_prefix :P It is just a convention...
Never forget: "Stay kul and happy" (I.A.)
David's thoughts / dnhsoftware.org / MyHTMLTidy
|
|
|
|
|
Since I used it, I would call it xmlNS. 
Excuse my ignorance: what the hell is Rotor?
[ITA] Tozzi ha ragione: Gaia si sta liberando di noi.
[ENG] Tozzi is right: Gaia is obliterating us.
|
|
|
|
|
|
As far as I know the CLS has nothing to do with naming conventions -- do you have any links to the CLS that provide member naming guidelines?
|
|
|
|
|
CLS naming guidelines can be found here.
|
|
|
|
|
Yeah I know about those naming guidelines - but they're not part of the CLS spec. I was specifically asking about the CLS naming guidelines that the author of the thread mentioned, and that I didn't think existed.
|
|
|
|
|
Amen and amen. I really dislike seeing underscores everywhere; heck, Microsoft scrapped an entire language (Managed C++) partially because of its ugly double-underscore syntax in favor a new sytax without underscores. That should mean something to developers: most people hate underscore syntax. I think the only place I use underscores is in event handlers: if there's a Button called buttonCancel, I might have a Click handler called buttonCancel_Click(object, EventArgs).
I disagree with the whole m suffix to signify member variables. If I want to access a member variable, I'll use the 'this' keyword. Honestly, in these days of autocomplete and intelligent IDEs, we don't need short abbreviated names, nor do we need suffixes or naming conventions to let us know their names; unless you're using a plain text editor (in which case, I wouldn't hire you), all the necessary information is available right in front of you. For instance, Visual Studio tells me the type of the variable as it pops up in intellisense, and also tells me if its part of my class. I don't need ugly naming conventions telling me the type or in which class it resides. 
I'm just glad the .NET framework designers realized the ugly all-uppercase conventions, the butt-ugly underscore conventions, the and cryptic abbreviated conventions, all of which the C & C++ languages and most libraries are plagued by, are done away with in the clean framework that is the .NET FCL.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Cops & Robbers
Judah Himango
|
|
|
|
|
I agree at all!
[ITA] Tozzi ha ragione: Gaia si sta liberando di noi.
[ENG] Tozzi is right: Gaia is obliterating us.
|
|
|
|
|
I had to vote 'Yes, and they must be adhered to'. I was the one that made the guidelines.
|
|
|
|
|
|
I've adapted my coding style a few times over the years to what the company was using, and all that I ask for is consistency. While some coding styles make me cringe, like m_, I can adhere to them if they are consistently applied.
The real problem occurs when I use some code that someone has kindly enough donated to CP. I actually spend the time going through and making it consistent with my personal style.
My personal coding style also goes way beyond variable name prefixes and other stuff like that. I should write it up one day.
Marc
My website
Latest Articles:
Object Comparer
String Helpers
|
|
|
|
|
Marc Clifton wrote:
My personal coding style also goes way beyond variable name prefixes and other stuff like that. I should write it up one day.
I'm sure plenty of people would like that !
|
|
|
|
|
Marc Clifton wrote:
While some coding styles make me cringe, like m_
Just wondering, what is wrong with "m_"? What is the better way to tell if a variable is a member of a class?
My articles and software tools
|
|
|
|
|
Xiangyang Liu wrote:
What is the better way to tell if a variable is a member of a class?
Well, in C#, variables are lower case, and properties are uppercase. And besides, everything is a member of a class. But you know that. The "m_" just seems redundant.
OK, I've seen cases where it can get confusing to distinguish between a parameter passed in to a method and a member field of the same name. I've actually been bitten by that once in recent memory. But even having been bitten by it, it was quickly identified and I personally didn't think it justified the m_ prefix. The better solution, in my mind, is a properly named parameter or field.
Sometimes I debate whether member fields should be accessed at all, as it seems that the property getter/setters are a more consistent mechanism and better overall architecture.
And finally, I find it aesthetically and technically displeasing. The information "m_" conveys is minimal, at best. Of course it's a member field, even without the "m_"! The only time it conveys meaningful information is when a parameter and the field name collide. And as I said before, I personally don't feel that that justifies the usage everywhere else.
Marc
My website
Latest Articles:
Object Comparer
String Helpers
|
|
|
|
|
Marc Clifton wrote:
And besides, everything is a member of a class.
What about local variables? When reading other people's code with many member variables and complex methods, it can be hard to determine if a variable is a member or not.
Marc Clifton wrote:
And finally, I find it aesthetically and technically displeasing.
I feel the same way about getter/setters, may be I am the only one. I got used to "m_" with all the MFC programming I did before and never thought it could be a pain for other people.
My articles and software tools
|
|
|
|
|
Xiangyang Liu wrote:
What about local variables?
I knew I was too darned asleep, when I wrote that post, that I was leaving something out. 
Xiangyang Liu wrote:
When reading other people's code with many member variables and complex methods, it can be hard to determine if a variable is a member or not.
With regards to my own code, I seem not to have that problem, for a variety of reasons. But yes, I've experienced that with other people's code.
Xiangyang Liu wrote:
I feel the same way about getter/setters, may be I am the only one.
I felt that way initially also when moving to C#, then I slowly began to see the benefits of getters/setters. The few concerns that I have is 1), it's taken until VS2005 for the IDE to be smart enough to generate the getter/setter, 2) they're function calls, so they're slower, 3) sometimes I really wish I could set one to public and the other to protected/private.
Xiangyang Liu wrote:
I got used to "m_" with all the MFC programming I did before and never thought it could be a pain for other people.
Hehe. I've done lots of C++/MFC programming, and I never liked nor got used to "m_" in that world.
What we really need is a realtime code-style filter that formats the code to our personal preferences. The underlying code can then comply with some standard that you or I or the team lead likes, but we get to view and edit it individually in our own style. Now that would be cool!
Marc
My website
Latest Articles:
Object Comparer
String Helpers
|
|
|
|
|
What we really need is a tool that automatically converts syntax to your prefered way of doing things. I'd like to have a tool that stripped out all the m_ naming conventions, uncaps the MAX_SHOUTINGS, forces fields to camelCase, forces public properties and methods to PascalCase, and so on.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Cops & Robbers
Judah Himango
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
