Naming rules

Hi all,
Is somewhere (codeguru, MSDN) a document which describes naming convention for variables, functions, methods, structures, classes in C/C++?
I found only Hungarian Notation article in MSDN.


Thanks in advance for any tips,
David

Herb Sutter has no time for Hungarian Notation: http://www.cuj.com/experts/1911/hyslop.htm

Try this: http://www.objectmentor.com/resource...les/naming.htm

I started off using hungarian notation but decided it was not good practice.

1- When you change the type of a variable, you have to change its name. It's annoying.

2- If you write short enough functions, you can easily see the type of a variable as it is just a few lines away. Thus a prefix is of no real use.

3- As you pointed out, there is no "standard" hungarian notation.

The only prefix I use on my variables is a hefty "m" in front of all my member variables (members of a class). Other than that, I just write the variable in plain english, without any underscore "_".

Of course, this represent my view on the topic, you are entitled to have your own views! ;)

The naming rule is whatever you and the people you are working with feel comfortable using. It works for some and doesn't work for others (mainly those who never have to maintain programs). You just have to agree a rule amongst yourselves and stick to it. You will need to watch out for the "not invented here" programmers. They will just wreak havoc with the naming.

Also there is the rule within the rule. eg if pointers begin with p, members of classes begin with m and handles begin with h, then which permutation of p, m, and h would a pointer to a handle which is a class member have? Again, some would say mph, others would say phm.

You may also need a file and class naming convention. For instance, looking for Manager in mgr.cpp, man.cc or mngr.cpp is annoying if you are new to the project. If they named it Manager.cpp, it would be easy to find.

I know this doesn't help a lot but naming is a very personal thing. Some like it and others loathe it (especially if they won't be there to reap the benefits).

Quote:

---

Originally posted by cup
...
Also there is the rule within the rule. eg if pointers begin with p, members of classes begin with m and handles begin with h, then which permutation of p, m, and h would a pointer to a handle which is a class member have? Again, some would say mph, others would say phm.
...

---

This example is part of what I'm talking about. This notation works fine with a very small team of 1 person. With bigger teams, everybody will have their own idea on what the order of the letters in the prefix should be. From experience, if you can't have a consensus on that topic, and it is utopic to think one can be reached, it renders the notation useless as only the person who wrote it can understand what it really means. If you have to go check the variable definition anyway, what's the point?

You should also be able to tell the type of the member (pointer, reference etc) by it's implementation.

i.e. student->setName("joe") ; indicates that student is a pointer where student.setName("joe"); is a reference...

I struggled with that question again and again and never satisfy! My point of view is when look at someone code, the first thing we want to know is "How to use this or that", not "What is this or that". So I think the type of a name is not as important as the scope of a name. Look at some name and you can know right away that whether you can use it, ignore it or can use it with some attention that would be great.

Ex: for a class if we can distinguish all public members from protected and private members it should be very good. Or we can tell whether a variable is global, a parameter or just a stack variable...

Anyone suggestion should be great.

What is wrong with Hungarian Notation? I do not think HN is the best naming convention possible. To those people who criticize HN, fine with me, but please propose your alternative, supposedly better naming convention here. If you have nothing better to offer, then just don't criticize HN.

In any measure, having a naming convention is much better than not having one at all.

I could never understand why people hate HN? Maybe it is part of the Microsoft bashing culture?

I like the idea of using name prefixes to identify the variable data type, like m_ for class member, g_ for global variable, p for pointer, n for unsigned integer, i for signed integer. a for array, r for reference, etc.

Quote:

---

1- When you change the type of a variable, you have to change its name. It's annoying.

---

You positively and definitely need to change the variable name when its type is changed, even if it is not because of naming convension. If a variable type or its usage is changed, chances are it no longer fits in the code where it originally fit. Name change gives you a chance to carefully review every spot the variable occurs, and make sure the code still makes sense.

Quote:

---

2- If you write short enough functions, you can easily see the type of a variable as it is just a few lines away. Thus a prefix is of no real use.

---

How do you know that your function will still stay short after a couple of months and some more changes? How short is short? How long is long? Where do you cut the line? It is better to maintain a consistent naming convention throughout the code set, regardless of the function size.

Quote:

---

3- As you pointed out, there is no "standard" hungarian notation.

---

So since there is no naming convension standard, you propose there should be naming convension to follow and every one just do their own naming and go ahead call their cats donkeys and they dogs monkeys?

Quote:

---

Originally posted by AnthonyMai
In any measure, having a naming convention is much better than not having one at all.

---

This I agree with.

Quote:

---

I could never understand why people hate HN? Maybe it is part of the Microsoft bashing culture?

---

At first glance, it just looks silly. Once you get used to it, you can't
think of variables any other way [I was there, trust me]. I think
people look at it and bash it without giving it a try because it
just plain looks retarded :)

Quote:

---

I like the idea of using name prefixes to identify the variable data type, like m_ for class member, g_ for global variable, p for pointer, n for unsigned integer, i for signed integer. a for array, r for reference, etc.

---

Will wonders never cease? I actually agree with a lot of this,
myself. I prefer to use m_ for class members, p for pointers and
g_ for global variables. I pretty much draw the line there, though.
My only real naming convention is to use have a capitalized class
name and have a lower-case object name [but each word would
be capitalized]
Example:

Code:

---

ExampleClass exampleObject(someValue, anotherValue);

---

You can't look at 'someValue' and "anotherValue" and know what
they are there for, but neither are the names descriptive. They
are just examples.

Quote:

---

You positively and definitely need to change the variable name when its type is changed, even if it is not because of naming convension. If a variable type or its usage is changed, chances are it no longer fits in the code where it originally fit. Name change gives you a chance to carefully review every spot the variable occurs, and make sure the code still makes sense.

---

I like how you say "positively and definitely" and then modify that
by saying "chances are". <shrug> Oh well ... details, details.

Quote:

---

How do you know that your function will still stay short after a couple of months and some more changes? How short is short? How long is long? Where do you cut the line? It is better to maintain a consistent naming convention throughout the code set, regardless of the function size.

---

... in my [AnthonyMai] opinion.

Quote:

---

So since there is no naming convension standard, you propose there should be naming convension to follow and every one just do their own naming and go ahead call their cats donkeys and they dogs monkeys?

---

I have to agree with you here, too. There are easy ways to say
that THIS is the one, true Hungarian Notation for THIS develop-
ment group. Whoever draws up the "outline" would specify all of
the pertinent rules.

Frankly, I don't use Hungarian Notation all too often any longer. I
used to use it ALL of the time; I grew accustomed to it and it
finally lost its appeal to me. I selected bits and pieces of it to use.
One rule of thumb I go by though: if you ever have to specify
the variables data-type in its name, then you're better off using
hungarian notation.
Example:

Code:

---

int intValue; // in my opinion, this is a bad name
int nValue; // in my opinion, this is a better name
int iValue; // as an alternate

---

I think that hungarian notation is so widely-used that the prefixes
are evident to most programmers ... and they do save typing.
I typically won't use any modifier on the name, though:

Code:

---

int queryValue;

---

That works fine for me :)

--Paul

If it is not Anthony Mai :p

Quote:

---

Originally posted by AnthonyMai
What is wrong with Hungarian Notation? I do not think HN is the best naming convention possible. To those people who criticize HN, fine with me, but please propose your alternative, supposedly better naming convention here. If you have nothing better to offer, then just don't criticize HN.

---

Even if I had nothing better to offer, please, leave me my right to criticize!

Quote:

---

In any measure, having a naming convention is much better than not having one at all.

---

True. But it has to serve a purpose. You have to decide why you are using a notation rather than blindly use it under the impression it is the "good" thing to do. Hey! If 1M programmer use it, it must be the way to go. I don't buy it. I used to use HNotation, I changed my mind.

Quote:

---

I could never understand why people hate HN? Maybe it is part of the Microsoft bashing culture?

---

Yes. But that's not because it is MS who initiated this movement with the help of Charles Simonyi a hungarian that *I* bash it. I bash it because I used it for years, then found a new way to program, with more efficiency. I found the use of prefixes obfuscate the code and doesn't really help and in fact keeps my coding pace low as I have to ponder to figure out a prefix to name this particular case for a variable: ex.: pointer to a pointer of char*...

Quote:

---

I like the idea of using name prefixes to identify the variable data type, like m_ for class member, g_ for global variable, p for pointer, n for unsigned integer, i for signed integer. a for array, r for reference, etc.

---

The only prefix I allow in my notation is prefix for scope.

Local scope is simple: no prefix
Member: m (without the annoying underscore)
global: g (never use it anyway)

I don't use other prefixes. for the exact reason offered by cup: How do you represent a pointer to an array of pointers anyway?!?! So much for clarity!

The lack of real standard also amazes me. For an integer, you would use i... but only if it is not an index, where you would use n... and for a string... sz... or s in some companies... Even the MFC code doesn't follow a clear convention! This shows me that "so-called" Hungarian Notation is failing to make the code clearer.

Quote:

---

You positively and definitely need to change the variable name when its type is changed, even if it is not because of naming convension. If a variable type or its usage is changed, chances are it no longer fits in the code where it originally fit. Name change gives you a chance to carefully review every spot the variable occurs, and make sure the code still makes sense.

---

FALSE!

If I change a pointer for a reference or a int to an unsigned int, under my convention, I do not need to rename my variable and do a search and replace to change the occurences. I only need to arrange my code (change * for & and such...).

If I don't need the variable, I delete it. That's it.

Quote:

---

How do you know that your function will still stay short after a couple of months and some more changes? How short is short? How long is long? Where do you cut the line? It is better to maintain a consistent naming convention throughout the code set, regardless of the function size.

---

That is also part of my convention. My function will grow with time. I fix a length I'm comfortable with as my max function length. Right now, it is 40 lines per function. If it grows beyond that,I need to refactor. I split the function in two or more. This is part of my extreme programming discipline.

Quote:

---

So since there is no naming convension standard, you propose there should be naming convension to follow and every one just do their own naming and go ahead call their cats donkeys and they dogs monkeys?

---

No. You call cats Cats, and monkeys Monkeys. And you know what? It's simpler, and easier to maintain. And that's my goal. I do not need cosmetic prefixes. The type of my variable is clearly stated out at the place where it is declared, therefore I have all the information I need to program.

Here is an example of how I code. This might look to you as a lack of convention ;) but for me, it is enough:

Code:

---

/**
 * Returns whether or not the file exists.
 *
 * @return true if the file exists.
 */
bool
        CFileName::Exists() const
{
        bool Result = false;

        const string Name = FullName();

        if ( Name.size() > 0 )
        {
                FILE * Handle = fopen( Name.c_str(), "r" );

                if ( Handle != NULL )
                {
                        fclose( Handle );
                        Result = true;
                }
        }

        return Result;
}

---

This is my proposal. And it works. Everybody at work uses it and our productivity hasn't suffered from it.

My point is: do what you want, do what works for you.

If Hungarian Notation is making you comfortable, by all means, use it. I personally find it is a waste of time.

Quote:

---

Originally posted by PaulWendt
Frankly, I don't use Hungarian Notation all too often any longer. I
used to use it ALL of the time; I grew accustomed to it and it
finally lost its appeal to me. I selected bits and pieces of it to use.
One rule of thumb I go by though: if you ever have to specify
the variables data-type in its name, then you're better off using
hungarian notation.
Example:

Code:

---

int intValue; // in my opinion, this is a bad name
int nValue; // in my opinion, this is a better name
int iValue; // as an alternate

---

---

Code:

---

int Value; // seems the best to me, although Value doesn't really means anything out of context...
// A less general identifier would be better!

---

Quote:

---

I think that hungarian notation is so widely-used that the prefixes
are evident to most programmers ... and they do save typing.

---

I totally disagree, and I think this is exactly the assumption everybody does and shouldn't. We all don't think alike!

What do you use as a prefix for a string? I've seen sz and I've seen plain s. To most of my colleagues coming from a Visual Basic background, s was the way to go, whereas for fellow C programmers, sz was unquestionable. Then, there was me, I chose s because it was 1 letter less to type :p

As I also pointed out, even Microsoft programmers don't all use the same notation for the same variable types.

Quote:

---

That works fine for me :)

--Paul

---

That's all that counts if you work alone.
If it works for others who will use your code, it's better ;)

Interesting topic.

I'm somewhere in-between hungarian notation and custom adaptation. I do use the g_ (global) , m_ (member) and p (pointer). I'm not sure if this is Hungarian notation, but I also use b for Boolean values. s is reserved for structure types, the ugly prefix "bstr" is what I actually use for BSTRs... Oh well...

But you won't see me prefix any DWORDs with dw, ints with int or these things. Most of the time they are not really relevant.

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.

I mean the point of all of this is that you make your code readable to yourself and a third party (your collegues maybe), so it's defintely better to call a variable "referenceCount" instead of "intRC". The point being that the type of a variable doesn't help you very much in understanding its purpose.

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.

Quote:

---

I don't use other prefixes. for the exact reason offered by cup: How do you represent a pointer to an array of pointers anyway?!?! So much for clarity!

---

I would use pMyObjPtrArray for it. It's a million times better than MyValue or something like that.

The idea is still valid that prefixing/suffixing variable names help with the readability. And as long as you want, you can use a name that clearly spell out what it is (the data type) and what it does.

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.

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.

Quote:

---

But you won't see me prefix any DWORDs with dw, ints with int or these things. Most of the time they are not really relevant.
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.

---

Forget about the OOP crap. Programming still boils down to basic manipulations of integers and doubles and signed or unsigned chars. Can you not pay attention to your data type?

You would pretty soon hate yourself for not prefixing DWORDs with dw, when you confuse a signed 4 bytes integer with an unsigned one, or when you started to try to make it work in a 64 bits operating system.

At minimal you should prefix something to tell whether the number is a signed or unsigned integer. Because in many cases signed or unsigned makes a big difference. Certainly if you never used an integer for any thing larger than what you could count with your fingers, that's another story.

Oohhh, I don’t want to cause this flame war. But thanks for all opinions, they are very interesting.
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. I think it is impossible to include all aspects of coding; it is not import if the variable is called mph_xx or phm_xx (btw. I think it should be m_phX).
I am sure this convention doesn’t cause that the code will be readable without problems, for that the code must contain a lot of comments of algorithms, functions etc. But I think it can help to understand the code better. If the variable is called “m_hMainThread” it is more readable than it is called “MainThread”.
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.
Of course, it is my point of view.

David

Quote:

---

Originally posted by proxima centaur
I totally disagree, and I think this is exactly the assumption everybody does and shouldn't. We all don't think alike!

What do you use as a prefix for a string? I've seen sz and I've seen plain s. To most of my colleagues coming from a Visual Basic background, s was the way to go, whereas for fellow C programmers, sz was unquestionable. Then, there was me, I chose s because it was 1 letter less to type :p

---

Like I said, there is a way to MANDATE which prefixes you use in
your organization. Just because there are different dialects of
Hungarian Notation doesn't mean that your organization can't
specify the rules for all of its employees to follow. Furthermore,
Hungarian Notation is NOT complicated once you get used to
SEEING a prefix in front of a variable name ... so changing from
nValue to iValue wouldn't be that big of a deal for someone used
to a different dialect.

Quote:

---

As I also pointed out, even Microsoft programmers don't all use the same notation for the same variable types.

---

See above.

Quote:

---

That's all that counts if you work alone.
If it works for others who will use your code, it's better ;)

---

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.

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

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: