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