My own Hungarian notation style

[rubenvb]

I'm planning on quite a huge project that handles lots of details (don't they all), and would like to teach myself a clear, good style for coding. I understand this is partially personal, but if I'm doing something utterly forbidden by <fill in the blank> or downright stupid, I'd like to know beforehand
Some questions:
1) I'm adapting hungarian notation, but hate the "standard", so here it is:
- (u)int: (u)i_...
- float: f_...
- double: d_...
- string: s_...
- size_t: sz_...
- (u)intptr_t: (u)ptr_...
- vector<string>: v_s_...
- vector<class T *>: vptr_...
- Constructor and simple set-function arguments meant to be put in the initializer list are not prefixed (data members are clear enough): say a class has an int and a float as data member, then the Class would look like this (I know, implementation in header is bad...):

class MyClass
{
public:
    MyClass(const float myFloat, const int myInt)
    :    myFloat(f),
         myInt(i)
    {    };
private:
    float f_myFloat;
    int i_myInt;
};

class MyClass
{
public:
    MyClass(const float myFloat, const int myInt)
    :    myFloat(f),
         myInt(i)
    {    };
private:
    float f_myFloat;
    int i_myInt;
};

To copy to clipboard, switch view to plain text mode 

That last bit just to avoid stupid mandatory renaming of the arguments.

2) The project is a build system for c/c++ and eventually other stuff as well. I read online that CMake has some (optional?) dependencies and that that sucks for a "build system", especially or using it on a tight-kept Linux install. But this means that stuff like directory listing and file access will have to be handled by me, in contrast to Qt's great functions/classes for exactly that. Thoughts?

3) Going on from point 2, for example getting directory listing (to resolve a search for all *.cpp files), there are two ways (except Qt of course):
- system(dir) and system(ls) platform specific and output parsing
- platform specific messes with native OS function calls.
The first is simpler in principle, but probably slower and harder to get right. The second will require lots of research by me.

Any comments are welcome, I appreciate all help/input/contribution.

[wysota]

To me hungarian notation only makes sense (if any) for non-object-oriented programming (like C) and when you don't have a decent coding environment. You have to think whether knowing the type of a variable is more important than knowing what it represents. If you have many classes in your project with similar names, prefixing instances of those classes with abbreviations from the class name will lead nowhere - there is no chance you will remember them all.

[squidge]

Personally, I adopt the coding policy document that I have to abide to at work, its easier than having two different standards for my own projects and work projects.

Whilst I can't for obvious reasons post the 100+ page document, a few things from memory that are differnt to your standard:

All class variables start with m_ (for member), to distinguist them from local variables and method parameters.
There are variable prefixes, but they don't match your list - instead of underscore, we use camel case. eg. 'bAbort' is a boolean variable, 'iCount' is an integer variable (unsigned/signed doesn't matter). String is 's' regardless of class. A null terminated string (eg. char * or char[]) is sz (eg. szTitle).

We use autocompletion, so the above helps shorten the list too, so when you see a function requiring a null terminated string, you can just type sz or m_sz depending on the scope you want. All class variables must be documented regardless of whether there usage seems obvious or not, local variables not so much. These comments show up in the autocompletion window to help you make a decision.

[SixDegrees]

As noted above, modern languages and development systems make keeping track of variable types pretty much pointless. If you like that notation, go ahead and use it. But I don't see any real benefit to be gained from it.

Personally, the only thing like this I use is a simple notation that keeps track of whether variables are class members or not. For instance, 'foo' denotes a simple, local variable, while anything prefixed with 'm' such as 'mFoo' denotes a variable that is a class member. Although even here, I'm inconsistent in my usage. It has come in handy, though.

As far as dependencies go, I don't think that's an issue. Development machines are nearly always loaded with all manner of tools and resources that the customer's target machine won't possess. They're there to help get the work done as efficiently as possible. So for a build system, at least one that's used during development, I wouldn't be worried about dependencies.

Where dependencies cause problems is when tools tied to them wind up being delivered to end users, who likely won't have them and who won't appreciate having to make additional downloads just to get an application up and running. This is another reason to hate cmake; when compared to the completely self-contained configure-based build system, it's an additional headache I simply don't need.

Also, frankly, cmake is a tool that solves a problem which doesn't exist. There are already plenty of time-tested means of building software projects out there that actually work; there's no need for another one, particularly one as bug-riddled and poorly documented as cmake.

In the end, do whatever you're comfortable with, and keep your end users in mind.

[squidge]

I agree, the only real benefit I see from prefixing variables (other than being slammed at code review meetings for not using them) is that it helps in calling methods. If your doing maintainance on code that hasn't been touched for 6 months or more, it's nice to reduce the list of variables to those that are truly compatible with an appropriate method call parameter. It's true that 9 times out of 10 if you choose the wrong one, the compiler will complain anyway, but If you can write code that requires fewer compile attempts, its a bonus (certainly when each compile can take several minutes each).

As for building code, "./configure && make" just simply rules and gets the job done. I don't want anything more complicated than that.

[wysota]

it's nice to reduce the list of variables to those that are truly compatible with an appropriate method call parameter.

Are they? What about implicit casting and inheritance? "Compatible" and "identical" are two different things.

And on the other end there is a situation when you want to find a variable holding some piece of information but you don't remember the type of the variable. It's practically impossible to guess the variable name without spending time to deduce what the type (or class) of this particular variable might be. Usually when I'm calling methods, I know what data I want to pass to it, I don't need them sorted by type, sorting by meaning is much more important to me.

[SixDegrees]

I'll toss in one more observation - I strongly recommend cranking your compiler's warning level up as high as it will go from the very beginning of any project, and working to eliminate ANY warnings that arise as they occur. This will catch most of the casting issues, and at least force you to insert explicit casts where needed.

Trying to do this with legacy code is often the stuff of nightmares, as literally thousands of warnings are thrown during a build. It does pay off in the long run, however.

[rubenvb]

Wow, a great series of replies!

Some counter-thoughts to explain my motivation for this (personal and more of an academic) project:
- ./configure && make works, only when it works, when it's broken, it's hell on a broomstick. Debugging the Makefile.am/in and the script itself, together with the "never-got-the-point-of" libtool, it's almost like you need to program your build along with the project itself. Add to that MSYS/Cygwin, which quite honestly suck (MSYS for compatibility and shell, Cygwin for speed and size), configure/make is not a good solution in my personal opinion. Time-tested yes, but broken in so many places.
- About the Hungarian notation: all valid arguments. I started using it only to prevent hidden casts from unsigned to signed and vice versa, and I'm teaching myself to use the right, *_t kind of types, which (should) work independently of platform or bitness. The notation would also be to prevent any compiler errors and limit compilation attemps.

As for building code, "./configure && make" just simply rules and gets the job done. I don't want anything more complicated than that.

Well... configure 1) takes too long 2) checks things a build system should know IMHO 3) is not "simple" in my definition of that word. CMake runs a shorter configure stage, but still depends on other tools to do the making. My tool will run all the commands itself, and use a simple project file layout.

PS: for those interested: www.gitorious.org/CAKE/wiki. It's a serious work in progress, but explains what my plans are. Perhaps a new thread is in order

[squidge]

Are they? What about implicit casting and inheritance? "Compatible" and "identical" are two different things.

The developer would still know what types that are trying to use, so it would still work.

And on the other end there is a situation when you want to find a variable holding some piece of information but you don't remember the type of the variable.

This is still possible, as typing any part of the variable name also shortens the completion list. You will then also notice the type from the variable name, so it would make it easier to notice which you need.

[wysota]

The developer would still know what types that are trying to use, so it would still work.

So... I need to have the whole inheritance tree in my head just to find out what the variable holding my FooBar is called? I still prefer to call my FooBar object foobar or m_foobar, regardless if it is an unsigned int or a QStyleOptionViewItemV4.

[SixDegrees]

I suppose I'd be remiss not to mention another, very simple build system that's readily available - qmake. I've been using it for a few simple, non-Qt projects lately, and it's hard to beat it for simplicity and speed of assembling a build system.

Not sure how well it scales to large, heterogenous projects, but it ain't bad for small to medium size tasks.

[squidge]

So... I need to have the whole inheritance tree in my head just to find out what the variable holding my FooBar is called? I still prefer to call my FooBar object foobar or m_foobar, regardless if it is an unsigned int or a QStyleOptionViewItemV4.

You misunderstand. You could type foobar and be offered the suggestion "m_szFoobar", the developer would know that he actually does want a null terminated string, so would select that option.

I've also fixed the quoting in my previous post that may clear up the confusion.

[ComaWhite]

I personally find that Hungarian notation just makes the code look like crap (Look at KVIrc's source code). And with modern IDE's (one's that aren't crap). can tell you a variable's type by hovering over it. Why you think Qt doesn't use all those crappy variable names? If you use it with an api that doesn't. Just makes it more confusing.

[squidge]

There will always be arguments for and against. For example, why force someone to hover over a variable to find out it's type when a quick glance will tell you the type without moving your mouse?

[franz]

I'd rather hover over the thing than having a glance at a variable called m_nFoo and concluding that it's a signed integer while some asswipe forgot to change the name to m_szFoo...

[squidge]

That kind of thing would be picked up at the software review stage and the appropriate engineer fired for being incompetent.

[franz]

*should be picked up.

Not abiding by hungarian notation is something I wouldn't consider being incompetent, but we all have our opinions