116 replies to this topic

[SigKILL]

Nick said:

... 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.

I´m sure this have been tried multiple times, but after a few employers have been through the firm (maybe some summer interns) I would guess that I atleast would rather give them a code convention paper and spend my time doing other stuff. One of the reasons I like the m_ convention is that it feels ´heavier´to do "m_myVariable = something;", than "myVariable = something;". It sort of reflect that you change something outside of the current scope, while local variables feels lighter to work with. When working with multiple threads it always makes me stop to think if I should have locked a mutex or something before doing this. I do agree that the ´heavines´ seems a little off-beat on lightwheight classes, but I´m willing to sacrifice that...

[SmokingRope]

Having a prefix convention helps solve any number of 'coders block' problems. While writing your code you know you need to use the prefix so you spit that out right away, then because it specifies what scope the variable is, you can more clearly declare the statement which affects that variable. Because the variable prefix describes the scope it also helps describe the context of the function/method clearly.

[Jare]

SigKILL said:

Parts of the code was not well written, so it might not be a good example.

Examples are no substitute for reality, no matter how good they are. Unless you actually want to avoid facing reality.

[bramz]

Nick said:

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.

Quite funny that a few pages back you found it sooo horrible that our codebase has code in several styles. Apparently, it's was sooo difficult to adapt. That's not longer an issue anymore? Way to go, Nick!

[SigKILL]

Jare said:

Examples are no substitute for reality, no matter how good they are. Unless you actually want to avoid facing reality.

:blink: Good examples are supposed to illustrate reality. If you avoid facing reality then reality will face you, and your example from reality will become a non-example in mind. :blink:

[Jare]

Well, bad codebases are a reality, why wouldn't they serve as a good example?

[Nick]

SigKILL said:

The main reason for not using hungarian notation is that the data type should be abstracted away.

The location of a variable should be abstracted away as well. Like I illustrated before, variables can change scope without changing roles, especially during refactoring, exactly like they can change type. I don't see why you treat scope and type prefixes differently. I believe the number of bugs caused by scope erros and type errors is pretty equal. And I need to know the types of variables more often (it's easier to remember whether it's a member

Quote

I´m sort of confused: do you dislike coding conventions in general?

No, but I dislike coding conventions that are ugly, leave no room for elegance, and can create misinformation. CamelCase is a useful style convention but it would be perfectly acceptable not to use it when there's a more elegant solution for a certain situation. And I'm quite picky about parenthesis placement and indentation but I once wrote code like this (names are symbolic):

if(flags & FLAG1) doA();

if(state > 0) {

if(flags & FLAG2) doB();

if(state > 0) {

if(flags & FLAG3) doC();

if(state > 0) {

if(flags & FLAG4) doD();

if(state > 0) {

if(flags & FLAG5) doE();

}}}}

This becomes an ugly 'staircase' when using general parenthesis and indentation rules (there are actually more stages in my code and the real variable names make it very clear what it does). So even though the convention is intended to improve elegance I had to deviate from it to get good code elegance. Just like with CamelCase this never causes misinformation.

Rules like 'm_' on the other hand are only meaningful when applied very strictly. You're relying on human hands to keep it consistent, and it becomes misinformation when you break it (intentional or unintentional). So you don't have any freedom. It also uglifies code instead of improving elegance.

The only option to keep things consistent is to back away from a strict convention that forces you to do a 'mechanical' task. You can either read the correct variable scope in the header file or use code assistance to do the 'mechanical' task correctly.

Quote

It really helps you being able to get to know new parts of the code fast.

I beg to differ. This is the second time you've used the word "fast" in this context, and it makes my skin creep. It is truely impossible to get to know code fast. Like I said before you end up writing bugs and breaking the design. You really have to study the headers to get to know the code. Just reading the functions, with scope hints or not, is largely insufficient. Personally I would never risk touching a class's code without mastering its design and keeping the header file right next to the source file or using other assistance.

Quote

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.

Every project needs guideline conventions, and people should adapt to them naturally.

If you make your rules too strict, you end up firing the most skilled team members who know how to think for themselves.

[Nick]

SigKILL said:

I´m sure this have been tried multiple times, but after a few employers have been through the firm (maybe some summer interns) I would guess that I atleast would rather give them a code convention paper and spend my time doing other stuff.

That's just horrible. I perfer to help my collegues and discuss coding aspects so we all learn from it. And it saves me work because they know a large part of what I know and can help me out just like I help them out. On top of that everybody has his own expertise and I adhere as much to their decisions as they adhere to mine. Sometimes we have to work out a compromise but in the end everybody agrees. Two are smarter than one, three are smarter than two, etc.

And speaking about summer interns: When I was interning at NVIDIA there was another intern who in one day fixed a bug which a team had been struggling with for over a week. So never underestimate people. If you treat them like equals they can and will teach you a few tricks as well.

Quote

One of the reasons I like the m_ convention is that it feels ´heavier´to do "m_myVariable = something;", than "myVariable = something;". It sort of reflect that you change something outside of the current scope, while local variables feels lighter to work with.

That doesn't work in the following situations:

class ABC

{

public:

    int a;

    int b;

    int c;

};


class XYZ

{

    void alpha()

    {

        ABC abc;


        abc.a = 1;   // Member variable used merely as local variable


        int &secondElement = buffer[1];


        secondElement = 2;   // Making a 'heavy' change through a local variable

    }


    int buffer[10];

};

A realistic situation is for example a wrapper class for a Direct3D vertex buffer. The wrapper class has the vertex buffer (pointer) as a member variable. But to fill the vertex buffer you need to lock it and retrieve a pointer. That's a local variable to do 'heavy' changes to the class state.

Anyway, there's no reason to be more careful with member variables, or be less careful with local variables. It's equally likely to cause a bug with either. After all local variables get assigned to member variables and vice versa.

Lastly, functions don't tell you with a prefix whether they change any member variable. SetFontType might change a member variable or a global variable or a singleton's member variable or call a Win32 function. Nobody adds 'm_' to an accessor function.

[Nick]

bramz said:

Quite funny that a few pages back you found it sooo horrible that our codebase has code in several styles. Apparently, it's was sooo difficult to adapt. That's not longer an issue anymore? Way to go, Nick!

It's definitely still the exact same issue. Noise. It's not because I ignore the prefixes that I don't care they're there. It takes effort to ignore them. To quote the blog SigKILL linked to again: "Visible to the point of distraction", "...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".

[SigKILL]

Nick: I start wondering if you have ever read a book on software construction. Good books include "The mythical man month", "Large Scale C++ Software design" and "Code complete". I´m very confused since your arguments doesn´t really make sense to me (or are really bad).

No one wants divas on their team, and I´m not seeing how a good programmer will have any problem adapting to strict coding conventions (and still be able to do a good job). It takes less time adapting to coding conventions than arguing why they are not good. And you work for a company, which owns the code you write so you better make it to their specification.

[Nick]

SigKILL said:

Nick: I start wondering if you have ever read a book on software construction. Good books include "The mythical man month", "Large Scale C++ Software design" and "Code complete". I´m very confused since your arguments doesn´t really make sense to me (or are really bad).

They do to a lot of people, if not the vast majority. The use of scope prefixes is not advised by Java and C#. The arguments are almost identical to those for not using Hungarian notation, which ironically do seem to make sense to you. Also, the blog you linked to contains much of the same arguments I've been using. Which makes me wonder why 'my' arguments really don't make sense to you (or are really bad).

In 'The Mythical Man Month' you might want to read about accidental complexity and essential complexity. The use of 'm_' falls squarely under accidental complexity. Also good reads are 'Refactoring to Patterns' and 'Software Architecture in Practice'.

Quote

It takes less time adapting to coding conventions than arguing why they are not good. And you work for a company, which owns the code you write so you better make it to their specification.

This way you avoid all discussion. You dislike Hungarian notation but 'm_' is not worth arguing about? If a company wants you to use Hungarian notation wouldn't you express any disagreement? I'm not saying you should break the conventions, heck I'd use 'm_' if I had to, but that has nothing to do with whether they are actually a good thing or a bad thing.

[davepermen]

i don't get why anyone would have to look into the header..? you only have to look at the function.. then you can see wich ones are parameters, wich one are function-local, and wich are (the rest) class-members..

of course, there are 'globals'.. but we all know we shouldn't use them, right? :D (and thus, when you need to use one, put it into a namespace, or use the ::GlobalAccessor)

SigKILL, you state there is no argument that makes sence made by me.. but there is.. the same as for hungarian: you don't need type information, it should be abstracted away. the NAME of the variable should explain it's usage (and thus, it's theoretical type..)

the same is for locality.. a variables name should explain as well, where it belongs to. myVariable and m_Variable will by a big chance be the same, but myVariable is more readable.. m_, what's that? my is a word everyone can understand..

myValue = newValue;
myValue = otherValue;

and this can even build up to more complex things like threadLocalContainer and stuff (where there is no simple m_ helping out).

it abstracts away the scope of a variable, wich should not be explicitely specified, just as the type shouldn't.

wether you build up some strange naming system like m_, p_, l_, g_, or something else, to find some general tokens, or you rather use your brain and think about what the value really is (this is a newValue (most parameters in constructors have that name), this is an otherValue (copy constructor), this is the originalValue.. etc..

[SigKILL]

Nick: If a company uses hungarian notation I would use it without argument. There is the discussion of good vs. bad coding conventions, and there is an discussion wheter to adapt to coding conventions or not. You should always adapt to coding conventions without argument (even if you might disagree with them). I thought I made that clear.

I´ve never heard anyone (except you) claiming that ugliness is the main argument against hungarian notation. See my previous posts why I don´t like hungarian notation.

I have a hard time convincing myself that scope should be abstracted away. All projects I have worked with the last 3 or 4 years have been multithreaded and changing a local variable vs. a member variable do make a huge difference. You could put enough mutexes around such that you´re always able to change things safely, but I have to be careful about which threads are locked. Anyways, when changing the scope of the variable adding/removing a prefix is the least of your problems. Just like your example when splitting functions you would read through the functions to make sure you haven´t broken some logic anyways. And typically in my experience; making a local variable to a member variable will change its role, since a local variable represent local (typically temporary) data/states, while member variables represent non-local class data (typically class states).

When it comes to Java, the Sun recommendation is to use PascalCase for member variables and camelCase for local variables (see http://java.sun.com/docs/codeconv/ ). I´m not familiar with C# conventions.

If you think that getting to know new code fast is impossible, you should try using strict coding conventions. It actually helps clearifying the logic (which is what matters IMO) when everything conforms to the same set of rules.

[SmokingRope]

davepermen said:

wether you build up some strange naming system like m_, p_, l_, g_

Don't forget:

mt_ for class template paramter
ft_ for function/method template parameter

[moe]

I have tried so hard not to answer to this thread but apparently I failed...

Quote

m_, what's that?

(realising you were ironic) In my head "m_" stands for member. Hence it indicates a member variable. If I say "my", it is as if it belongs to me but that can't be right. It belongs to the class. So, I personally don't like it if the "m_" is missing and I dame sure hate "my". The same goes for the type. I prefer if it is there.

In fact I prefer if you go from general to special much like in inheritance. Therefor, I have names like "m_iNumTriangles". As you see I also stress the importance to have an accurate name. But in addition to the prefix and the type.

In my opinion It take too much time if I need to hover the mouse over the variable or if I need to check the headers just to get the scope or the type. Even so it's not actually long :lol:

Anyway, I would dare to say in the end everything is just another naming convention. Even leave the scope and the type asside is just another convention. In other words: You can't argue about taste... And in my opinion that's the only reason why discussions about naming conventions won't die. There is no solution. There are just opinions. So, no offence to anyone.:lol:

[Nick]

moe said:

m_iNumTriangles

Gee, I wouldn't have guessed 'numTriangles' was an integer... :rolleyes: And when working in some kind of Mesh class it doesn't take a genious to determine that it's a member variable. No offence really.

Even if I do have to check the header file, I only have to do it once. A prefix distracts me each and every time I read that variable. And it's not just annoying to read. That example requires 5 extra key strokes. Considering how little the prefixes are of use, and how cryptic they are (they're not fluently typed English words), that's a lot. Don't overengineer naming conventions. With all the variations people invent, it's just much nicer not to use them at all and leave it up to the reader to determine scope and type, without risk of misinformation. I'm fine with reading the context and the header, davepermen loves his IDE's features. Above all we refactor the code when it becomes more complicated than necessary (using more informative names, splitting up big classes and functions, getting rid of accidental complexity, etc). K.I.S.S.

I think I summed it all up in one paragraph, so I'm just going to leave it at this. If you're forced to use scope and/or type prefixes, fine, use them and keep things consistent. But if you get the choice, at least consider these arguments and try to work without artificial prefixes. That's all for me. :happy:

[moe]

Quote

Gee, I wouldn't have guessed 'numTriangles' was an integer...

Ha, you fell into my trap :)
In similar situations the dx-api used DWORD's so I might have used m_dwNumTriangles for consistency witch you didn't realize since you're not used to prefixed. (Or you hate them so much that it prevented you from seeing more.) So even if you do not need the prefix yourself it helps to keep things consistent witch I think is important. Besides if one uses a trivial sample it apparently is not enough. But if you make it more complex everyone shouts out that it doesn't fit a real live situation any more.

Quote

Even if I do have to check the header file, I only have to do it once.

Hmm, I wonder witch one it is... Do you have a photographic memory or do you only work in small source codes... :)
I certainly need to check things more than once. Maybe I am just not smart enough (Hence, I need the prefixes to remember) :)

Quote

5 extra key strokes

Since I have my hands on the keyboard it still takes less time than leave the keyboard move the mouse and wait until the tool tip pops up. Then move the mouse aside to see again what's under it. Or switching into the header...

Quote

But if you get the choice, at least consider these arguments and try to work without artificial prefixes.

I did consider your arguments and I think you put quite some thoughts into it. It's just that I have a different taste. Isn't it more interesting if not everyone is the same... :)

Quote

That's all for me.

I must have hit at least some soft spot since you give up now :)

Quote

No offence really.

None taken and none intended (therefore all the smilies). Anyway, I hope you are not mad at me now.
I agree it's time to move on. I will desperatly try not to answer to this thread again as well. Or maybe a moderator could close it? After all it did start as something completely different and we are way off topic.