|
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
|
|
|
|
|
Yes, writing code is an art. Yet the art is not in its presentation, but rather its meaning. Because of this, code style conformity is a virtue. When one reads two novels by two different authors, one doesn’t expect there to be differences in the layout of sentences on the page, nor differences in characters used to express inherent meaning. Rather, it is through conformity that one is freer to appreciate the writing. Indeed nonconformity in coding style detracts from its meaning, and obscures interpretation.
When I code in Java, I use Sun's guidelines[^]. When I code in C#, I use Microsoft's[^]. Microsoft spent a lot of energy coming up with their guidelines and made some good choices.
I wonder how many C# developers are aware of the Microsoft guidelines, and who have read and follow the conventions therein. I know there are many that do not. Curiously, from my own observations, the proportion of Java developers that adhere to Sun’s guidelines appears to be greater than the proportion of C# developers that adhere to Microsoft’s. One may speculate on the reason for this disparity.
Code conventions are important in team environments.
I find it a hindrance reading C# code with Hungarian notation or fields prefixed with ‘_‘ or ‘m_’; or needless use of ‘this’. This is because such styles are not what I’m used to. When I first started using C#, I adopted the use of a prefix ‘_’ for member variables. Fortunately after a couple of weeks I stopped this practice when I realised it was unnecessary, and that it violated the MS guidelines. I now know that when practices, such as those mentioned above, become necessary it is indicative of poor design.
Indeed code style is a contentious issue. My advice though is to follow the language vendor’s guidelines because it saves a new developer from having to learn your organisations custom style conventions, and expedites collaboration with others outside of your organisation.
Microsoft Design Guidelines for Class Library Developers[^]
Sun Code Conventions for the Java Programming Language[^]
Daniel Vaughan
Zen Diaphragm
|
|
|
|
|
I can't say it surprises me any more, but developers are spending way too much energy on less important aspects of coding standards/guidelines, like naming conventions. It is not that important whether to prefix a member variable with m_. A much more important thing is to design your types correctly, to write exception-safe code, to document your work properly, to have code reviews...
Definitely the best book on coding standards[^] (C++ specific) I am aware of does not even mention things like naming conventions and placement of curly braces.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-- modified at 10:22 Tuesday 30th August, 2005
|
|
|
|
|
If your message isn't worth a 5, I don't know what is. Amen!
Good music: In my rosary[^]
|
|
|
|
|
They say Programming is an 'art' why do they then ask us to follow these conventions...  ?? Should'nt an artist (programmer) have free hand? 
|
|
|
|
|
Depends - do you want to get paid for your art?
|
|
|
|
|
|
Ali I. wrote:
They say Programming is an 'art' why do they then ask us to follow these conventions... ?? Should'nt an artist (programmer) have free hand?
The main reason is that it's usually a group effort. If you always work alone, then it won't matter what conventions (if any) you follow. But in a group, it makes a difference.
Alvaro
Explain to the mothers & fathers of American servicemen that may come home in body bags why their son or daughter have to give up their life?" -- Sean Hannity, 1999.
|
|
|
|
|
End of the day... you are not the owner or the 'gate keeper' for the art. Sor, make the art understandable to the next person too - so follow some guidelines
"He that is good with a hammer tends to think everything is a nail."
- Abraham Maslow
|
|
|
|
|
S P S wrote:
End of the day... you are not the owner or the 'gate keeper' for the art.
Depends on where you work and what your job function is. Since I am the only windows programmer in my department I am the only person responsible for the 500K+ lines of MFC code that I have written in my current job (since early 1997).
John
|
|
|
|
|
OK, exceptions ruled out 
"He that is good with a hammer tends to think everything is a nail."
- Abraham Maslow
|
|
|
|
|
Yep, a couple years ago when we were a real software development team, we came up with a pretty good coding standard. The funny part was reaching the consensus. All important points (use of smart pointers, STL, standard strings, documentation, ...) we resolved quickly and unanomously, and then lost weeks arguing where to put curly braces 
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
On a new line, right? :P
regards,
Paul Watson
South Africa
Colib and WebTwoZero.
K(arl) wrote:
oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
|
|
|
|
|
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)
