|
|
WHY WASN'T THE SHOUTING NOTATION AN OPTION?
--
Talk to the hand!
|
|
|
|
|
we were talking about coding, not AOL-ing
"if you vote me down, I shall become more powerful than you can possibly imagine" - Michael P. Butler.
Support Bone
|
|
|
|
|
java: isTime
c++: m_isTime
delphi: IsTime
|
|
|
|
|
I normaly follow this...
For Function Names 'PascalCaps' --> like, My GoodBadFunction ()
For Variable Names 'Camel Caps' --> like, sweetVarToDie
For Constant Names 'Hungarian' --> like, _Conat100
I was born intelligent Education ruined me!.
|
|
|
|
|
SPS wrote:
For Constant Names 'Hungarian' --> like, _Conat100
That is not hungarian. Hungarian notation is something like this:
long nSomeLong;
const char* lpszString; Where the prefixes n and lpsz describes the type (or kind rather) of the variable.
--
Berlin - Die heimliche schwedishe Hauptstadt.
IKEA
Wohnst du nach oder lebst du schon?
|
|
|
|
|
I aprobe some new standard, that's all, JAVA embraced UML, can't see why we dont.
|
|
|
|
|
Religion, that's what it looks like to me. All of you have an opinion, but very few can come up with a valid reason for it. Your reasons seem to be nothing but eggs and tomatoes.
Ask yourself this question: why should you use a naming convention (or coding conventions in general)? Is it for your personal satisfaction? Is it so that you can produce more lines of code per hour? Is it so that when you go back to maintain your code, you will be able to understand it better?
My answer to all of the questions above is yes. But there is one far heavier reason than all the ones above: It is so that the person who will maintain your code will understand it better. This person could be you, but in most cases it’s not. And if it’s not, it doesn’t matter if you think Camel Caps is an invention of Gods if the person taking care of your code doesn’t.
The answer to what naming convention to use is not found in your religion. The answer can only be found by doing an experiment where some programmers get to interpret the same code, but written with different styles. Only the outcome of this experiment will tell the truth.
|
|
|
|
|
What I think is that, each of us have our own style of naming. So long as we are consistent with ourselves, I think we will not have any problems understanding the codes. Unfortunately, alot of programmers I have encountered, do not have this word in their dictionary.
I can easily see a varible with word separated by underscore on one part of the codes; another part of the code the camel notation appeared suddenly. They don't seem to understand the importance of a orderly and consistent way of coding. If such a codes is produced, I think it would be fair to say, the code can be thrown in the the garbage bin, as it is worthless.
|
|
|
|
|
I use Hungarian, but my CS professor requires everything in camel
but then again everything is in python
Matt Newman
If you chose to continue this discussion, I am fully prepared to make you my bitch. I invite you to ask around, and you'll find out that I'm quite capable of doing so - John Simmons on Trolls
|
|
|
|
|
Matt Newman wrote:
I use Hungarian, but my CS professor requires everything in camel
You will thank that professor later in life.
No single raindrop believes that it is responsible for the flood.
|
|
|
|
|
Navin wrote:
You will thank that professor later in life.
Maybe for the camelNotation, but probably not the python
Matt Newman
If you chose to continue this discussion, I am fully prepared to make you my bitch. I invite you to ask around, and you'll find out that I'm quite capable of doing so - John Simmons on Trolls
|
|
|
|
|
Actually, I've wanted to learn Python, but haven't had the time. It seems like it could be good, and a lot less hairy than Perl, to embed into programs needing scripting support.
Either that, or write my own language..
No single raindrop believes that it is responsible for the flood.
|
|
|
|
|
Navin wrote:
Actually, I've wanted to learn Python, but haven't had the time. It seems like it could be good, and a lot less hairy than Perl, to embed into programs needing scripting support.
It should be easy for you to learn, but it is overly simple. Not declaring types and absolutely no puncuation gets a little annoying, especially when you try to go back to a real langauge.
Matt Newman
If you chose to continue this discussion, I am fully prepared to make you my bitch. I invite you to ask around, and you'll find out that I'm quite capable of doing so - John Simmons on Trolls
|
|
|
|
|
ya yes jjj
|
|
|
|
|
the east or the west side.
It's about the dark side! Hungarian notation rules. You're wrong. Next!
--
Must I be the meat in an imbecill sandwich?
|
|
|
|
|
Jörgen, you been smoking again?
regards,
Paul Watson
Bluegrass
South Africa
Brian Welsch wrote:
"blah blah blah, maybe a potato?" while translating my Afrikaans.
Crikey! ain't life grand?
|
|
|
|
|
Yes, Hungarian m_crkPipe of course.
--
Must I be the meat in an imbecill sandwich?
|
|
|
|
|
As I noticed some discussions here and also in real life people usually say that what they have it`s best even if they know it isn`t. I`t the way people think. If they have a bad car they`d say anything that makes it look good even if they don`t believe it. Same applies here. The people who use hungarian say it`s best and ppl who use camel say that`s better. I used to programm in vc++ using hungarian and then when I tryed c# and camel I saw it was better than what I was doing before. I was getting tired of calling m_strVariable and m_img and so on in my code. In functions I even had to replace m_nPointCount for example for a local variable count or smth like that. Hungarian can be usefull to tell the variable types appart but when you really starter programming you realise that camel is better. No excess typing. With good naming you can obtain type recognition results same as hungarian with less code. Some programmers that used hungarian with c++ for years got used to it and aren`t even thinking of giving it up. I was the same but when I tried c# with camel I realised that it was nicer. The ones that haven`t tried both types in my oppinion shouldn`t comment on wich is best because for sure they`ll say best is the one they`re using. I tried both. Camel is nicer for typing and aspect.
|
|
|
|
|
Well, I've tried both. I switch back and forth between various types. I tend to go with hungarian notation when I do Windows programming, because it's kind of standard there. When I do UNIX programming I use the small letters and underscore. When I do Java (when I have to that is), I use Java naming. When I do C#, I do hungarian.. mostly because it just feels right.
Also, when I do STL-like code, I go with "UNIX"-naming, because that's how STL is written. Thus my code will look better if it matches the looks of STL.
I really don't have a problem with any of the types. I just think it looks silly if I'm using one convention in an environment which uses another. I just go with the flow.
Why being so damn hung up on notation anyway? Hungarian notation isn't hard to read. Just ignore the prefix It may be a bit more to type, but I'll gladly type the extra characters to make my code looking not too alien in the environment where it is running.
--
Berlin - Die heimliche schwedishe Hauptstadt.
IKEA
Wohnst du nach oder lebst du schon?
|
|
|
|
|
|
You are correct
To all you vader haters out there
|
|
|
|
|
That flash flick is soo damn funny! I think I'll watch it again.
--
Berlin - Die heimliche schwedishe Hauptstadt.
IKEA
Wohnst du nach oder lebst du schon?
|
|
|
|
|
I had to vote "Other" since I use a mix of conventions for different purposes... some were listed, some were not.
ALL_CAPS_WITH_UNDERSCORES: constants/defines
camelNotation: Local variables. Also used for private member functions.
mMemberPrefix: member variables of classes
PascalNotation: Function and class names, and enums
.. and occasionally some others come up as the need arises.
Almost never use Hungarian or any kind of type prefixes. I sometimes use "p" for pointer, but I don't really know why. It doesn't seem to help anything, but yet I feel compelled to do it. About the only time I use any kind of type prefix is when I have code that converts stuff between two different types. Then it makes sense to have, say, a string and an int of the same name, so I need to tell them apart.
I didn't use to prefix member variables with an "m", but out of a compromise for our coding standards, I have been doing so. It has mixed results... it is kind of a pain, but at least it solves the problem of member functions that set variables - you no longer have a name clash.
No single raindrop believes that it is responsible for the flood.
|
|
|
|
|
Navin wrote:
ALL_CAPS_WITH_UNDERSCORES: constants/defines
camelNotation: Local variables. Also used for private member functions.
mMemberPrefix: member variables of classes
PascalNotation: Function and class names, and enums
Looks fine as mine... Where r u from Navin?
I was born intelligent Education ruined me!.
|
|
|
|