The idea of variable prefixes
The idea of prefixes on variable is “very” old. They are used to tell the developer what kind of variable he is using. The first prefix for example is m_ and the conclusion is this variable is a member. When I learned programming we had to give the developer more information in case of a member. Like the type of it like an integer became m_i. Here is a list of type prefixes we had:
- i : integer
- i8 : 8-bit integer
- l : long
- s : string
- c : char
- u : unsigned integer
- f : float
- b : boolean
I think you see the pattern 😉
But as you expect this is not all of the truth. Now the other side of the ‘_’. The first part of the prefix contains the scope of the variable.
- m : member of this class/type
- s : static member of this class/type
- g : global member
As I told the prefixing is old and were very helpful because the development environment could not help as much as today. Today we have very good IDE’s which can highlight code as you want. A static variable will be displayed in another color or font as a local variable. Today is the prefix of a variable like a comment which must be maintained. Sometimes the variable will become another type and the name is not changed. At this point it is not a help in contrar it confuses. A variable name should tell what it contains and not how. So it is more important to give them a meaningful name instead of a prefix which have to change with the next refactoring.
- Type can be seen without assistance of an IDE just from name.
- You see the name space/the scope.
- Name must be changed if type is changed.
- Redundant information (with actual IDE’s)
- A wrong prefix is confusing
If you use a very old programming environment it can make sense to use the prefixes. But in most cases you should avoid it. If you see prefixes in old code you should remove them. If you see it in new code ask the developers why they are using them. And if necessary tell them how to set up the IDE for a better code feeling.