m_pui32CurPos = Pointer to a 32-bit unsigned int, and it is a class member.
[/quote]
Ugh.... You've dedicate more space to the Type, (i.e. the thing you can see by hovering your pointer over any instance of the variable), than the purpose. What is CurPos? Current position? Cursor position? Something else?

i32Total = 32-bit integer. Not a member of a class and not a parameter.
_ui8Mask = An 8-bit unsigned integer that was passed to the function.
[/quote]
The types for these should be visible on the screen, or within a single "Page Up". If not, maybe you should add "Keep functions short, to less than a single screen if possible" to your convention.

When you pick a style, be consistent in that style. A style is useless if it cannot be trusted. ... Decide for yourself...
[/quote]
These points are certainly true.

Personally, I used to use Hungarian notation when I was an intermediate level programmer. Since then I've changed my programming style such that I find it isn't necessary. Now I find it ugly, distracting, and a maintenance burden.

m_pui32CurPos = Pointer to a 32-bit unsigned int, and it is a class member.

Ugh.... You've dedicate more space to the Type, (i.e. the thing you can see by hovering your pointer over any instance of the variable), than the purpose. What is CurPos? Current position? Cursor position? Something else?[/quote]
Ironically, although your goal was to propose a situation in which the naming of my variable could be misunderstood, still your first proposal was exactly what was on my mind.
It is the current position, and I named it based off human intuition. Most humans will see it as such when they read it.
Of course, one will be able to decide between the choices you proposed based off whatever kind of function it is, but had I felt the intention of the variable was not clear, I would have made my variable name even more explicit.

i32Total = 32-bit integer. Not a member of a class and not a parameter.
_ui8Mask = An 8-bit unsigned integer that was passed to the function.

The types for these should be visible on the screen, or within a single "Page Up". If not, maybe you should add "Keep functions short, to less than a single screen if possible" to your convention.[/quote]
I hope one day we shall all live in a world in which it will be possible to view only single-screen functions.
But that is not the only threat that variables named without metric information can propose a problem.
Actually, given the types of problems caused by variable metrics, I wonder why metric information would not be available constantly.
It really isn’t a matter of what is convenient. Yes, you can wait for a little yellow balloon to appear. It is not so much trouble. But did you know you were even supposed to show that balloon? Did you even know that the metrics of the variables in play are the cause of the bug?
Without metrics you look only at the algorithm. With metrics, you look at both the algorithm and the implementation of it.

When you pick a style, be consistent in that style. A style is useless if it cannot be trusted. ... Decide for yourself...

These points are certainly true.

Personally, I used to use Hungarian notation when I was an intermediate level programmer. Since then I've changed my programming style such that I find it isn't necessary. Now I find it ugly, distracting, and a maintenance burden.
[/quote]
And still I have used Hungarian for well over a decade and never had a problem with it. My speed at typing ui32 is considerable, and everyone will adjust to whatever style he or she chooses.


The one downside to styles is that they challenge one’s aesthetic perception of his or her own code. A lot of people cannot accept the logical explanations behind how some styles help given how unpleasant the code looks.
Personally, I only feel unpleasant when not all of the code in the entire project is consistent. Whatever the style, I want to make it all look the same.
I recognized early that a lot of people were willing to appease their aesthetic visions of code in order to satisfy their disregard for logic, and I had promised never to be such a person.
That is why you don’t see me talking poorly about any given style or another, and why you can see many places in which I have advocated the choices of each individual.

Let people decide for themselves. People love it when others agree with them, but I am not willing to guide someone down a path he or she did not choose just to make one more person who agrees with me.
The original poster should take all of this as input, filter out what he or she does not like, and use the rest.
Let it be that simple.


L. Spiro