On the other hand, a naming convention that clearly distinguishes parameters from local variables, that's something useful.
I'd add that a naming convention that distinguishes between in/out parameters and const vs. mutable variables could be useful, too.
I still like Hungarian over camelCase. I tried to like it, but it just don't...
How often are you looking at code in a browser? Are you ever writing code in the browser?
github.
On the other hand, a naming convention that clearly distinguishes parameters from local variables, that's something useful.
I'd add that a naming convention that distinguishes between in/out parameters and const vs. mutable variables could be useful, too.
I'm still kinda pissed that C++ didn't make const the default storage qualifier, at least for parameters, because you need it more often than not.
Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.
I still like Hungarian over camelCase. I tried to like it, but it just don't...
How often are you looking at code in a browser? Are you ever writing code in the browser?github.
You're coding directly in github?
FTFYI still like CamelCase Systems Hungarian over camelCase Hungarian. I tried to like it, but it just don't...
. 22 Racing Series .
I read people's githubs often.
Shogun.
What I'm puzzled about here is: how is knowing the type actually useful? If you see something like CountOfItems += 1, how is it more useful to see nCountOfItems += 1? Or likewise with PlayerName = "Captain Meteor" versus lpszPlayerName = "Captain Meteor"?
It seems to me that Systems Hungarian just satisfies some form of programmer OCD moreso than anything else; if so that's cool, but I've never seen an argument I can buy that otherwise justifies encoding the type in the variable name.
Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.
Well, C/C++ has some crazy implicit casting rules which will probably result in warnings or even errors these days, but that wasn't always the case. I suppose it could also make some sense when mixing with assembly etc which was probably common back then. I occasionally use some form of systems hungarian to group related vars in intellisense, in particular when working with GUIs (buttons, labels, text boxes etc), but other than that, I hate it.
I can't believe that in 2015 we are still discussing Systems Hungarian.
I wonder if Ross and Rachel will ever get together? Also I hear Seattle has this hot new sound called "grunge".....
It helps if a library matches your own coding style exactly, but it's not a big deal.
Sometimes it's nice when 3rd party libraries use a different style, visually distinguishing lower-level code from higher-level.
It'd be cool if IDEs could color your functions differently depending on what regex-matched header they came; both within your own project and from third-party libraries. Just a thought - probably wouldn't be too useful though.
I'd add that a naming convention that distinguishes between in/out parameters and const vs. mutable variables could be useful, too.
I wish C++ required that non-const references were assigned using address-of operator, like pointers, so you'd have:
int &myRef = &myVar;This way, by glancing at the outside of functions, you can see whether the variable is being modified:
DoSomething(&meow); //'meow' must be getting modified.
