Naming rules

A lot of this notation business stems from what you think is important. I think it is important to know

1) whether an identifier is global and where it is defined
2) whether an identifier is a member of a class
3) whether an identifier is and input/output/variable parameter of a function.

With globals, I just tag on the file where they have been declared. This forces me to keep the filenames short and it also makes the variable names easier to type. When you do this, there is no need for specialized search tools or these wonderful IDEs which show you the definition because you know exactly where to look for the definition.

Beyond that, I'll go with the flow of what other people think is important. The compiler will sort most things out anyway unless the coder goes crazy on casting.

Quote:

---

Originally posted by AnthonyMai
I can't believe that some one consider attaching a u or i in front of a variable is a waste of time. How much time could you have wasted in typing one extra character? By omitting that one character in variable name you could easily waste a few days instead of a few hours in tracking down a dummy coding bug.

---

It is not a waste of time when you type it, it is a waste of time when you try to figure out what's wrong. See below.

Quote:

---

Here is an example. Can you tell what is wrong with this code:

Code:

---

    if (myValue < 0)
    {
        // Do something
    }
    else
    {
        // Do something else
    }

---

You can't tell what's wrong? It is so obvious what's wrong to me by just glacing at it. But you could probably look at it one hundred times and still don't know what's wrong. Now let's try it slightly differently. See this time if you can tell me what's wrong?

Code:

---

    if (uMyValue < 0)
    {
        // Do something
    }
    else
    {
        // Do something else
    }

---

You see? You see!!! By adding an extra u, it immediately becomes crystal clear that the abobe code must be wrong. u means unsigned unmber. An unsigned integer could never ever be smaller than zero. So the logic of above code must be wrong. If this is a bug, I can spot in in one minute by looking at the u, and you could be spending several days without realizing this is a problem.

---

No. I don't see. For all I know, you declared your variable:

Code:

---

int uIFyooockedUpMyNotationOops;

---

How can you assure me beyond "good faith" that the uWhatever is an unsigned? See? That's my point, you assume every programmer is going to make no mistakes in giving a name to a variable, yet, you don't assume he won't make any mistakes in programming? Nonsense! Your argument is as good as goo-goo! :)

See, for the same reason you want to use it, I don't want to use it.

You feel it is safety for you to see a letter that duplicates the type of a variable, whereas I find it is duplication of meaning and can cause to ambiguities or errors.

And I'm not just talking here to say the opposite of what you say just cause I like it. I've experienced some kind of Hungarian Notation and errors like I've just described happen all the time.

I agree with you, if you could ensure that no programmer is going to make a mistake in naming a variable, HN is a real productivity booster. However, it is not the case and I can't believe people who believe it is! That's like people who believe in astrology to me! :P

Quote:

---

Originally posted by PaulWendt
You have to make it work. If you're not in a position where you
get to make the decisions, then you all should come to some sort
of agreement, whether you use Hungarian Notation or not.

---

I totally agree. However, the cost of making it work is high for HN. I prefer K.I.S.S. Keep It Simple Stupid. The expectations are minimal, therefore there is a better chance of having a consesus and keeping with the convention established. To make Hungarian Notation work, you almost need to hire a policeman to make sure people are using the good prefixes :p

Quote:

---

Frankly, I don't even use it excepting m_ and g_; I don't often
NEED the type of the variable in my variable name. The point I
was trying to make is that the different flavors of Hungarian
Notation are so similar that reading another flavor [and getting
used to it so that you use it on a constant basis] wouldn't be
too difficult.

--Paul

---

I'm not saying that I don't get what sz or s or n means. I'm saying it is error prone, thus not for me. I like things to be clear cut.

Quote:

---

Originally posted by Yves M
...
I'm not sure if this is Hungarian notation, but I also use b for Boolean values.
...

---

And you know what? Nobody can tell you whether or not it is Hungarian Notation because in fact, Hungarian Notation is not defined! Hungarian Notation is an "idea" coming from a memo document! It is a suggestion, not a standard so for all you know, somebody could be using b for bytes or bo for bool... who knows?

Quote:

---

I read that Herb Sutter link by Graham and it does make sense to me that in the days of OOP you should not have to use these prefixes anymore.

---

Right on.

Quote:

---

...
In my company I'm known for the guy with the annoying descriptive function names. I actually use functions like TransformPortionTextFromRTFToDisplay. Well, some people hate it (me too when I can't copy-paste the function name :p), but it makes the code very readable.

---

And you don't need to add tons of comments as your code is self explanatory. Very good practice. Your colleagues might be annoyed right now, but in 2 years, when they have to change a feature in your code, they'll thank and bless you with all their heart.

:)

Quote:

---

Originally posted by David Bajgar
Oohhh, I don’t want to cause this flame war. But thanks for all opinions, they are very interesting.

---

Hehehe! Well, if you didn't know that Hungarian Notation was a touchy topic, now you do! :D

Quote:

---

Well, this is an idea from my boss. He wants to unify a writing of codes in our company. The main reason is: the code must be better readable for others in the company. If a programmer leaves the company others must be able to read his code.

---

Then, in my opinion, on top of a coding convention, have a way of documenting your code easily. I suggest you use doxygen for documentation. It is easy to implement and the programmer only has to document "on the fly" as he/she codes.

Quote:

---

I think it is impossible to include all aspects of coding;

---

That's why you have to keep your convention to a minimum set of rules that are very general. This way, it is easy to apply.

Quote:

---

The other point of view there is the experience. Senior programmer which is used to write code in first way he doesn’t want to write code in second way. I am sure it will bring the chaos into his code.

---

Use Hungarian Notation, and talk to me about chaos in two years.

Quote:

---

Of course, it is my point of view.

David

---

And you should be proud to express it!

Actually, given the statement that something was wrong with the code, my first thought was to suspect that the variable was unsigned. Admittedly, given that there's not much else there, it doesn't take a genius to figure it out, but if a whole if/else clause is never getting activated, and there's a "< 0" in there...... I honestly doubt that it would take long to discover. However, if the variable had originally been a signed int, with an "i" prefix, and someone had later changed it unsigned, but neglected to change the name - well, then it might take a lot longer to work out.

BTW, cup: in your list of "what it's important to know", I'd add:

0) What the d*mn thing is for. Its purpose, why it exists.

"szText" may tell me that it's a zero-terminated string, but "UserEntryString" gives me more of a notion of what entity it represents, and a few clues (in context) to its purpose and use. "htItem" tells me that it's an HTREEITEM for a tree item, but b*gger-all else. "selected_item_handle" tells me a lot more about it. And before anyone accuses me of skewing the examples, I see so many of the szText/htItem around that I feel justified in using them. It's classic case of thinking that giving type information makes up for not giving it a descriptive name ("well, you know its type, what more do you want?") as if you could determine purpose from type. And I suspect there's more than a little desire to keep the names short (much easier to type htItem than selected_item_handle).

Oh, and if MyValue is unsigned, then presumably it's unsigned for a reason, and that reason should preclude its being checked for < 0. Or, if it does need to be checked against < 0, then it shouldn't have been made unsigned. Or was it unsigned's "turn" to be used as a variable type? ("I haven't used an unsigned int for ages, I think I'll use one now.")

Quote:

---

From Graham
BTW, cup: in your list of "what it's important to know", I'd add:

0) What the d*mn thing is for. Its purpose, why it exists.

---

That is one of my failings. I normally only put in the reasons for 30% of the identifiers. But then again, nobody is perfect.:D

Quote:

---

No. I don't see. For all I know, you declared your variable:

code:-------------------------------------------------------------------------
int uIFyooockedUpMyNotationOops;
--------------------------------------------------------------------------------

How can you assure me beyond "good faith" that the uWhatever is an unsigned? See? That's my point, you assume every programmer is going to make no mistakes in giving a name to a variable, yet, you don't assume he won't make any mistakes in programming? Nonsense! Your argument is as good as goo-goo!

---

Are you actually thinking using your brain? I can't believe some one would make such a weak argument.

First please do not put words into my mouth. I did not show you where I declared my variable. I also never made any sort of assumption that any one can be error free, on any thing.

People make all kinds of mistakes in all kinds of things. That does NOT constitute any reason at all against having any sort of rules or convensions.

So you are proposing NOT to have a naming convension just because occationally people may not follow the naming convension correctly, simply by mistake?

Why don't you also propose abolishing the traffic regulations because people run at red all the time, by mistake or by intention?

Maybe we should also abolish the C/C++ language standard altogether, because people WILL make mistakes that breaks the standard?

One basic assumption every one needs to make is human error is always a possibility.

When I see a variable name staing with a u, First I assume I should not assume that any of my assumptions are always correct without exceptions, second I assume it is an unsigned integer if every thing goes as I expected, third, I assume I could be wrong and some one made a mistake in naming the variable in the wrong way. Fourth, I assume every thing is possible and the only thing evetually counts is what I see with my eyes.

And after all, having a naming convention is still a good idea.

Quote:

---

However, if the variable had originally been a signed int, with an "i" prefix, and someone had later changed it unsigned, but neglected to change the name - well, then it might take a lot longer to work out.

---

This is why I insis on ALWAYS change variable name if the variable type is changed. By changing the name where it declared, you will be forced to change it every where it occurs so you have a chance to inspect every spot to make sure that the code still makes sense with the new variable type.

Note such name change should NEVER be made using "Find and Replace All". It should be done one at a time. It may take a little while longer than doing a "replace all", but it saves you trouble in trying to figure out what went wrong later.

Quote:

---

Originally posted by AnthonyMai


Are you actually thinking using your brain? I can't believe some one would make such a weak argument.

---

<laugh> There's the endearing AnthonyMai we've all come to
know and love.

Quote:

---

And after all, having a naming convention is still a good idea.

---

... in my [AnthonyMai's] opinion.

--Paul

And when you're done arguing with that, let the real flamewars begin!

Code:

---

This:

    for (x=0;x<10;x++) {

          MyFunc(x);

    }


vs.

    for (x=0;x<10;x++)
          {
              MyFunc(x);
          }

---

The bloodloss alone on whether there should be a space before and/or after the ;'s in the for statement is beyond comprehension.

Neither.

This:

Code:

---

    for( int x = 0; x < MaxSize; ++x )
    {
          MyFunc(x);
    }

---

Fixed:
1) indentation
2) spacing
3) use of magic number
4) ++x vs. x++ (small performance increase)

Jeff

Quote:

---

Originally posted by jfaust
Neither.

This:

Code:

---

    for( int x = 0; x < MaxSize; ++x )
    {
          MyFunc(x);
    }

---

Fixed:
1) indentation
2) spacing
3) use of magic number
4) ++x vs. x++ (small performance increase)

Jeff

---

Should it be an int or an unsigned (int) ? ;)

This style of coding is the one I use. However, I tend not to use variables such as x, y, i, j, k as they usually HAVE NO MEANING! :p
The worst are ii, jj, kk and such double or triple letters variables.

Unless you are dealing with unit vectors or mathematical topics that already use that notation, I tend to avoid it.

as for images, I use "Line" and "Col" rather than x and y or i and j or u and v :rolleyes: