116 replies to this topic

[davepermen]

hm.. i can hear myself speaking in this forum... uuuhhh...


:D

no, but really.. the problem would be solved if this-> would be mandratory.. not optional. of course, nobody would want that, because the shortcut (leaving out this->) is so handy..

wellwell.. i don't use any of those things.. but i do catch myself sometimes call the class-local variable "myVariable".. and very often, the passed parameters with same name will get a new in front.. that means:

class Vector {
   float x;
   float y;
   float z;
   public Vector(float newX, float newY, float newZ) {
      x = newX;
      y = newY;
      z = newZ;
   }
}

and in the same way, if i write some assign operator, it would be otherX, or what ever..

thats less general than the m_ p_ and l_, but then again, it does only implicit state the variable-locality-type. instead it describes what the variable is actually ment for.. this is the new value, this is the original value, this is another value, this is the old value.. etc..

i prefer names that simply describe a variable for it's purpose. everything else is, for me, non-useful overhead.

[Jare]

Nick said:

I'm sorry but it's not a religious debate.

Lacking a formal definition of what a "religious debate" is, I'll offer two ideas:

- It has (repeatedly) shown up in pretty much every programming discussion forum for a long time. And never managed to generate anything near a reasonable conclusion, rather ending only when all the parties grow bored.

- Arguments are either reduced to expressing personal preferences, or rely too much on peripheral or circumstantial details for validity and applicability.

It's perfectly fine to offer opinions, ideas, experiences and even bits of knowledge about these topics, but there's a point when the debate degenerates into desperate attempts at justification, or even worse, absurd statements. To me, ideas like "an experienced programmer doesn't make such trivial mistakes anymore" or "why would you want a compile time error there in the first place?" fall squarely in that category.

[Nick]

Jare said:

It has (repeatedly) shown up in pretty much every programming discussion forum for a long time. And never managed to generate anything near a reasonable conclusion, rather ending only when all the parties grow bored.

I'm sorry if you got bored. I myself found davepermen's post one of the most interesting and learnful. Also juhnu's suggestion is worth some thought.

And discussions like this do get conclusions in the long run. Hungarian notation is advised against in C# style guides and on its way out. And I'm telling you, 'm_' is next.

Quote

Arguments are either reduced to expressing personal preferences, or rely too much on peripheral or circumstantial details for validity and applicability.

I'm sorry, but which of my six primary arguments were expressing personal preference? Or which rely too much on peripheral or circumstantial details? To me they are pretty much facts but I'm willing to reconsider them if you would be so kind to point out the flaws.

Quote

It's perfectly fine to offer opinions, ideas, experiences and even bits of knowledge about these topics, but there's a point when the debate degenerates into desperate attempts at justification, or even worse, absurd statements. To me, ideas like "an experienced programmer doesn't make such trivial mistakes anymore" or "why would you want a compile time error there in the first place?" fall squarely in that category.

My aplogies. I realize those are blunt statements. I'll rephrase the thought: When someone encounters his first bugs caused by using incorrect types, Hungarian notation looks like an excellent idea. And for that person it can actually help for a while to be reminded of using types correctly. But it complicates things for other people in a team who learned to be aware of these problems and deal with them without artificial rules. They need to learn a new cryptic code, spend time applying it correctly, uglifying their code, and not getting any real benefit from it. After a while, the person who experienced his first type bugs makes far less mistakes, finds them trivial to debug, and has far worse logic bugs to deal with where no change in notation could ever help. The fact that he makes less mistakes with types can hardly be attributed to Hungarian notation, he just learned to be aware of them and is more careful when he encounters similar situations. The rest of the time, Hungarian notation is noise for him as well, but he'll probably still advise his team members to use it because it once helped him and might help them as well. While in fact it's more likely that newcomers will go though a phase where they make type errors as well, Hungarian notation or not.

It's almost exactly the same with the use of 'm_'. Everybody makes member vs. local vs. argument variable bugs at some point. And then some people will use whatever means necessary to prevent those bugs. But the fact of the matter is that you just can't prevent them at all. You can only learn from your mistakes and become more aware of potential bugs. You create a discipline to test these things (both code-wise by looking at the exact declaration, and execution-wise by checking the desired behavior). The use of 'm_' just ends up being noise when you have to deal with real logic errors. It might even make people too confident that their code is correct, while testing is the only way to make sure. And ironically many don't blame the use of 'm_' when they do find a bug like this, but instead thinking they should use it more rigorously (causing them to spend/lose more time with unhelpful notation and forcing it upon others).

Now, before anyone jumps at my neck: I'm not claiming that a person who uses Hungarian notation or 'm_' is an inexperienced programmer who still has a lot to learn. Programming has many aspects and everybody encounter certain bugs at different times; some while still learning the guts of the language, some after years of experience. But I do believe that the use of 'm_' is an overreaction to try to eliminate these bugs while actually after a while most if not all people deal with them by building more awareness, testing more, and looking up the exact declarations. Writing 'm_' stays behind like a scar...

[SmokingRope]

I just went through and cleaned up some of my more recent classes to ensure i had proper naming conventions for all my variables. This included using proper caps/lowercase, fixing some 'bad' names and placing prefixes on the code.

I noticed that by having an 'm_' in my variable name it was much easier to do a find and replace on the right variable throughout complete source files.

On the other hand conducting a find and replace with a variable name which had not been properly prefixed returned any number of false positives.

*Especially any variables with names less than 3 characters in length*

[Nick]

SmokingRope said:

I just went through and cleaned up some of my more recent classes to ensure i had proper naming conventions for all my variables. This included using proper caps/lowercase, fixing some 'bad' names and placing prefixes on the code.

I noticed that by having an 'm_' in my variable name it was much easier to do a find and replace on the right variable throughout complete source files.

On the other hand conducting a find and replace with a variable name which had not been properly prefixed returned any number of false positives.

*Especially any variables with names less than 3 characters in length*

Great, so would you use fully qualified names from now on to simplify that particular situation even more?

namespace X

{

    class Y

    {

        void X::Y::a()

        {

            X::Y::x = 0;

        }


        int X::Y::x;

    };

}

Now you can search/replace anything with almost no risk of screwing things up. Woot! :w00t: Or maybe we can go back to C or even assembly and make every variable global so it has to be unique...

Seriously now, that's a very far-fetched 'advantage' of using 'm_'. If you used more meaningful names from the start you would have never needed it. Davepermen's suggestions could be very useful. Granted, I too have to refactor names once in a while and have to locate its uses, but it's definitely not worth it to uglify my names with a prefix. The whole purpose of the refactoring was to prettify them. This situation should be a lesson to take some extra time to come up with meaningful names, not to keep using 'm_'.

In Visual C# 2005, there's even a Refactor menu, where you can just select a name, rename it, and all its uses change with it without any risk. That's the direction we're heading and should keep heading. :worthy:

[SigKILL]

My ´m_´ convention is inspired by McConnells book ´Code Complete´, where it is given as an example of a naming convention. I guess everybody agrees that there should always be a global naming convention. The problem I see with not naming a varible after it´s scope is that I read C++ code fast and I hate having to stop reading the source code whenever the scope is not clear (that includes looking three lines up to look for the declaration).

This could ofcourse be helped with a coloring scheme, but I don´t really believe in the idea of writing code for IDE´s. I have to admit that your (Nicks) reasons for not liking ´m_´is very little convincing. The variables role should be reflected in its name, and using ´m_´seems like a nice convention. I only use m_´s in classes though. I have a few structs spread around that mainly hold data. These do not use the m_ convention.

[SmokingRope]

Nick said:

Now you can search/replace anything with almost no risk of screwing things up.

That's a very important point right there.

[Jare]

Nick said:

I'm sorry if you got bored.

I said these threads only end when people get bored. The fact that I'm answering in this thread indicates precisely that I'm NOT. Yet. ;)

Nick said:

which rely too much on peripheral or circumstantial details?

The usual example: "m_" adds a much larger amount of noise/signal to a member named "x" than to a member named "InternalUnicodeCharacterMap". That's why sweeping generalizations such as "m_ adds noise" are not useful facts when establishing comparisons and analyzing tradeoffs.

[Nick]

SigKILL said:

The problem I see with not naming a varible after it´s scope is that I read C++ code fast and I hate having to stop reading the source code whenever the scope is not clear (that includes looking three lines up to look for the declaration).

I take it you use Hungarian notation as well then so you can read non-stop? :surrender

And I like to read code reasonably fast as well. That's exactly why I avoid adding any kind of cryptic prefix that repeats itself over and over again. I typically also remember what I read three lines up...

Quote

This could ofcourse be helped with a coloring scheme, but I don´t really believe in the idea of writing code for IDE´s.

If you don't uglify your code with prefixes the reader is free to do what he likes. That can be hovering the mouse over variables only when necessary, arranging the header and source file in two columns, looking at arguments and local variables, or indeed a coloring scheme. Everybody can read it without decrypting, and it's more likely to focus on elegance (e.g. davepermen's approach). So it's not relying on IDE features per se, but it is 2006 and they are available for everyone.

If you do add prefixes, you force your preference upon others. It's utterly useless when combined with the way I like to read code. And I don't want to learn your habits and everybody else's Hungarian dialect. My code, just like davepermen's, expresses exactly what is intended, so nobody can really have a problem with it.

By the way, if you don't believe in writing code for IDE's, can I ask what source control you use? Or do you prefer keeping all the old code in the source files as well? See, it's for the better that we do rely on some tools to be available one way or another, to improve code/coding quality... It's indeed a bad idea to code for one specific IDE, because that would again force your preference upon others, but you don't have to deny the existence of coding assistance completely. There are sufficient ways to determine a variable's scope (and type) efficiently without mutilating the actual code.

Quote

The variables role should be reflected in its name...

Absolutely, but whether or not it's a member variable is of little importance to its role. Consider this situation: You have a long function and you wish to split it up. There will no doubt be variables that need to be available in each part, so you have the option of either storing them as class members or passing them as function arguments. They are stored somewhere else, but the code is still perfectly equivalent, and the roles of variables hasn't changed whatsoever. Reversely, you can also merge functions when you see their functionality isn't needed separately, and you can make some member variables local. So exactly in what form a variable appears is quite irrelevant to the logic, the stuff that really matters.

newX, otherX, globalX, tempX, etc, these are useful to understanding the code.

Quote

I only use m_´s in classes though. I have a few structs spread around that mainly hold data. These do not use the m_ convention.

And you expect the readers of your code to adhere to this exception instantly? What makes a struct so different from a class? Do you expect people to constantly check whether they're working with a struct or a class? It's another perfect example of misinformation. Thank you for that.

[Nick]

SmokingRope said:

That's a very important point right there.

What point? I hope you realize I was being sarcastic. The risk of screwing things up with search/replace is no better with 'm_' appended.

[Nick]

Jare said:

The usual example: "m_" adds a much larger amount of noise/signal to a member named "x" than to a member named "InternalUnicodeCharacterMap". That's why sweeping generalizations such as "m_ adds noise" are not useful facts when establishing comparisons and analyzing tradeoffs.

An adult with a penis on his forehead isn't better off than a baby with a penis on its forehead even if it does help determine the gender. :rolleyes:

Anyway, by your logic you should make every name as long as possible to minimize the noise part. Or, since you admit it does add a lot of noise at least to short variable names, the argument could also be used to justify omitting 'm_'. But that breaks consistency and makes it unreliable. So either way you twist it, you end up with noise.

The alternative is pure elegance. Give variables the names you really want to give it, without warts (or penises). Use what works best for the situation and clarifying the logic: x, newX, nextElement, internalUnicodeCharacterMap...

[davepermen]

m_ doesn't help to describe what a variables purpose and use is. it does only define where it's stored.. and this should not be needed, just as it should not be needed in the name what type a variable is (hungarian notation).

this is the compilers job to determine wether something is used the right or wrong way, and the ide's job to realtime detect and red-underline it.

and instead of renaming by search-replace, you should rename by help of a refactoring-tool in the ide, that actually renames only your variable, not the string that has the same name of your variable.
at least in vc# 2005 ee, this works great :D

oh, and, tahnks nick, to understand what i wanted to say :D

[SigKILL]

I´m sort of hoping that you´re kidding, Nick. The purpose of a coding convention is to avoid a number of local deciscions by making (a few) global decisions. I expect anyone that work with my personal code to adapt to my coding conventions (which can be described in less than a page). A programmer has to adapt to new coding conventions every time he work on a different project/team/firm (depending on company policy), so I´m not sure what your point is. I´ve worked at one company where there was no m_ convention, and this really got to be a problem at semi-large projects (hovering mouse, looking through headers, looking through that small block of code that declares 6 new variables). Parts of the code was not well written, so it might not be a good example. The only valid argument in your posts (IMO) is that you think prefixes are ugly. I´m not convinced by that since it is obviously a personal preference.

P.S. Programmers are not idiots (I´m not claimin everyone is smart, though ;). There are no problem using the m_ convention for private class members and not it in data-structs. There are no problem not using the m_ prefix in you vector class either. Coding conventions is not absolute. You always have the liberty to do some local quirks as long as it is well documented.

[SigKILL]

davepermen said:

m_ doesn't help to describe what a variables purpose and use is. it does only define where it's stored.. and this should not be needed, just as it should not be needed in the name what type a variable is (hungarian notation).

this is the compilers job to determine wether something is used the right or wrong way, and the ide's job to realtime detect and red-underline it.

and instead of renaming by search-replace, you should rename by help of a refactoring-tool in the ide, that actually renames only your variable, not the string that has the same name of your variable.
at least in vc# 2005 ee, this works great :D

oh, and, tahnks nick, to understand what i wanted to say :D

Where it is stored actually help a lot. If I´m unfamiliar with the function updateInternalSystems() in the large SuperTanker class, I can simply read through the function and know (without looking at the header) what the class looks like (actually what the class that is of my interest looks like). It is so easy to not see (or to forget) the float in "float tankVolume = blah,blah,blah;" before the first morning coffee..

If you want it to be the compilers job to determine if something is right or not, you should probably not use C++. I´m not sure how this is an argument against the use of m_. The ´looseness´of C++ allows for quite many tricks that are ackward in many other languages (try making a singleton class in VB5, its icky).

The problem with writing for the IDE is that I might port (atleast parts of) the code to another platform. If I´m able to use one cross-platform IDE that might be fine, but I´m not keen about linking to one specific IDE (there might be a better one out in a few years, or the company that creates it might not exists).

I´m not religous about the use of m_, but I would think good coders (as Nick and permen) is able to see the advantages of a naming convention. It is also an surprise that you have so many arguments against m_, but none that actually matters (except it being ugly).

[Nick]

davepermen said:

this is the compilers job to determine wether something is used the right or wrong way, and the ide's job to realtime detect and red-underline it.

and instead of renaming by search-replace, you should rename by help of a refactoring-tool in the ide, that actually renames only your variable, not the string that has the same name of your variable.
at least in vc# 2005 ee, this works great :D

I agree Visual C# 2005 is great, and we'll be able to rely on IDE tools more and more in the future, but it's a bit wrong to assume that's the standard yet (especially for other languages). It's not an argument for using 'm_', I'm just saying there are many other ways to determine the scope of variables. My favorite is having the header and source file in two columns. If you have them underlined, that's awesome, but I'm just pointing out that's not always available and there are plenty of alternatives.

Quote

oh, and, tahnks nick, to understand what i wanted to say :D

You're welcome. I really love your suggestions and will try to use more of such hints where appropriate. Having unique variable names is a good thing and can be a valuable alternative to 'this->x' when it improves elegance.

[SigKILL]

Some thoughts about this in C#
http://blogs.msdn.co.../09/178816.aspx

[Nick]

SigKILL said:

I´m sort of hoping that you´re kidding, Nick. The purpose of a coding convention is to avoid a number of local deciscions by making (a few) global decisions.

I'm certainly not kidding. I hate being forced to read all different conventions for a variable's scope and type.

Quote

I expect anyone that work with my personal code to adapt to my coding conventions (which can be described in less than a page). A programmer has to adapt to new coding conventions every time he work on a different project/team/firm (depending on company policy)...

That's manageable when working in the same closed environment for months or years. But it's a pain when working with code from different projects. Do you write all the conventions on the wall? What happens when you break one?

I don't have the time to adapt to people's artificial code conventions. When I see code that uses scope or type prefixes I ignore them, so they are nothing but noise. I just always end up checking the declaration to avoid misinformation. Code without them isn't littered with redundant information that I've already read. It's generally more lucid.

Quote

I´ve worked at one company where there was no m_ convention, and this really got to be a problem at semi-large projects (hovering mouse, looking through headers, looking through that small block of code that declares 6 new variables). Parts of the code was not well written, so it might not be a good example.

There you go. Using 'm_' wouldn't have improved it one bit. It's badly written code and making it adhere to some artificial convention doesn't make it any better.

Too often I see scope and type prefixes being used as an excuse for not using more informative variable names. When I read 'm_pszString' it tells me jack shit. When I read 'fileName' I know exactly what it's for (with a bit of context of course). I don't really care if it's null-terminated string or an std::string, next week it might be something different and still have the same role. But I do want it to be clear from the variable's name what that role is.

Quote

The only valid argument in your posts (IMO) is that you think prefixes are ugly. I´m not convinced by that since it is obviously a personal preference.

Wait a second. You agree it's a valid argument that it's ugly. But then you change that to being a personal preference "obviously". Once again let me ask you: Do you use Hungarian notation? Why (not)?

It's an ugly wart any way you look at it. It's some cryptic character(s) with an underscore. It's dangling at the side of the variable name (hopefully one that gives me some real information).

Quote

P.S. Programmers are not idiots (I´m not claimin everyone is smart, though ;).

Which is exactly why they don't need to be reminded of every variable's scope and type over and over again.

Quote

There are no problem using the m_ convention for private class members and not it in data-structs. There are no problem not using the m_ prefix in you vector class either. Coding conventions is not absolute. You always have the liberty to do some local quirks as long as it is well documented.

I think it's a major flaw. If you want to adhere to a convention, do it right or it becomes misinformation. If I was to adopt the convention and I don't see 'm_' I want to be sure it's not a member. With your variation I can never be sure and have to check the declaration anyway to see if it's a struct's member. I would end up just ignoring it and it would be nothing but ugly noise. And it can get worse. What if you decided to make a class a struct or a struct a class? Are you sure that removing 'm_' doesn't break anything, or you're adding 'm_' to the right variables? You can easily get confused by your own code. Even when structs are treated equally, you can never guarantee that it's always correct. With bramz's approach you can even have different conventions in a single project. That's all misinformation leading to confusion and actually ignoring them all. But then it's already too late and you're pretty much stuck with it for the rest of the project.

[Nick]

SigKILL said:

It is so easy to not see (or to forget) the float in "float tankVolume = blah,blah,blah;" before the first morning coffee..

But you wouldn't miss prefixes? Take it as a friend's advice: Drink some coffee before leaving for work. Take your time to read the header file, it's there for a reason and contains lots of other useful information. It's very important to have an overview of things so you don't feel like you're in a maze of code. I know countless situations where a person thought he had fixed a bug but actually wrote a dirty hack or coincidentally avoided the bug, while breaking the design and/or introducing new bugs.

Quote

It is also an surprise that you have so many arguments against m_, but none that actually matters (except it being ugly).

Again, do you use Hungarian notation? Its ugliness is the main reason why people avoid it when they can (to me the only valid situation for using it is in a typeless language). After all why would anyone make his code ugly? It's a very important argument, or we wouldn't have this many discussions about style.

Besides, people who prefer a prefix don't have a real problem reading code without prefixes (but can have problems with other people's dialects), while people who avoid prefixes do get annoyed by the ugliness.

[Nick]

SigKILL said:

Some thoughts about this in C#
http://blogs.msdn.co.../09/178816.aspx

Nice discussion, thanks!

I believe the most important thing is to give it a serious thought. When working in a closed environment and the code won't be used outside the team and ever member agrees, then sure, use scope prefixes and stick to it if that's what you really prefer. But when the code is going to be read and written by inside and outside people I think it's best to avoid any discussion and not adhere to a convention. Just let everybody deal with how to determine a variable's scope their own way. It can also motivate them to think a little longer about variable names that are clear for everyone, and make them spend more time in header files so they get a better understanding of the design.

Anyway, my favorite quotes from that blog:

• Full Hungarian notation: Avoid this like the plague.
  
• Underscore notation: Visible to the point of distraction. I feel if I need the hint in the first place, then perhaps there should be more encapsulation or fewer locals occurring in the code.
  
• Semi-Hungarian notation: If your classes have so many member / local interactions that you absolutely need a system for separation to keep things straight, it may be an indication of design issues. Often, re-evaluating encapsulation, class hierarchy, and interface will give you more manageable code than simply using prefixed names as a band-aid. I have used them myself, and I've found the biggest challenge is sticking with the scheme once I've started using it. If I have a few member variables that I'm using one time each in two member functions, it's exceedingly easy to get lazy and not follow my own naming convention. Suddenly my code is that much less readable for having used the convention in the first place.
  
• No prefixes: I am comfortable with this style because it helps me to think critically about my own data localization. Used correctly, this is the most elegant solution, but can also lead to the most problems when dealing with many developers with a range of development experience.

He's right about that last thing. It can lead to some problems with developers with a 'different' experience. But I highly doubt that using prefixes is the right solution (as also indicated by the previous points). They'll have some problems for a while with or without them, and you'd annoy everybody else with the 'training wheels' for the rest of the project. In my opinion it's best to help them become aware of potential problems, learn how to debug and test them, and how to write clear code and read other people's code fluently using the available tools.

[SigKILL]

The main reason for not using hungarian notation is that the data type should be abstracted away. Other reasons includes that it combines meaning with representation and encourage uninformative names (like the well-known hwnd). However, the scope matters. I´m willing to sacrifice beauty over functionality any day (to a certain extent), and I don´t agree that the m_´s are ugly; I only said it was a valid argument. If I could trust every programmer to give variables a name such that the scope is obvious I would never consider the m_ convention. I have every reason to believe that a ´good´ name for a class member might sound like a good name for a local variable for another programmer . You can´t fail the name ´m_tankVolume´, it´s the class member that represents the tank volume.

I´m sort of confused: do you dislike coding conventions in general? and I´m not seeing how your other arguments is in disfavor of the m_ convention (I might have missed something?). Working on a few big projects I have to say strict coding conventions is a must (along with refactoring). It really helps you being able to get to know new parts of the code fast. If someone breaks the conventions in a non-obvious way, it is managment problem (you should have code review). You should always adapt to companys coding conventions. I´ve heard several stories about people being fired because they are not able/willing to adapt.

I´ve never had any problem turning data structs over to classes. You would have direct access to my data structs member variables, while you access class members through functions. Data structs have at most constructors and destructor and no member functions.

EDIT: Oops, this is reffering to your 04:03 post.