Easy question for you vets out there:
What is the accepted (assuming there is one...) prefix for a CString variable name? For clarification, I've seen the following for other data types:
int iIndex; //integer
int* pIndex; //pointer
bool fFlag; //bool flag
And there are countless others. Please feel free to let me know if this is really a non-question or something with a "Whatever you want" answer.
Prefixes such as those are an abuse of the concept of Hungarian Notation.
The idea of HN is that a variable is prefixed with a code describing its use. e.g., a variable holding the count of something would be prefixed cnt; a variable holding an index would be prefixed inx. A variable holding a flag would be prefixed f. A variable holding a number (that wasn't a count or an index or something else common) would be prefixed n.
However, soon people got lazy, (and largely due to that last example) and the prefixes started to be just an indication of the data type. This has some use in C, where the declaration of a variable had to be at the top of the function, potentially some distance from where it is used. (especially when code was written in a simple text editor)
But, eventually, we got more type safe languages, and better IDEs, so the faux-Hungarian Notation because unnecessary and scorned.
There is none. Never prefix a variable with its type. See Making Wrong Code Look Wrong for the correct use of prefixes.
There is no standard for notation in a variable name. In fact, with better development environments (with intellisense, etc.) it is highly unnecessary.
I've seen "s" used. Example: sIndexname.
I use "m" for a data member: mIndex, and "p" for a pointer to a data member: mpIndex. I only use them for class-scope variables. That's it.
By today’s "standards" even that is pushing it. AFAIK, except for a few Microsoft diehards Hungarian notation is dead. I am especially amused when I see it used for local variables that are used exactly once 2 lines later. Fun.
For some reason I am repulsed by the "m_" convention. It's just ugly, imo. :-)
Related
Is there any advantages of defining variable names as __00000001, __00000002, etc.?
Example:
int __00000001, __00000002 = 0;
for (__00000001 = 0; __00000001 < 10; __00000001++) {
__00000002 = __00000002 + __00000001；
}
...
Update: this is mentioned in one of my programming classes a few years ago, and I remembered that the professor said there is some advantages of using it. However, I cannot recall any more information. Maybe I am wrong.
Those particular variable names are not available for user programs:
All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. (C11, section 7.1.3, paragraph 1)
So that's a big disadvantage.
Is obfuscating the crap out of your code worthwhile? No, not unless your goal is literally to do just that: to make your code as hard to read as possible. Trouble is, you've got to read it too.
Sometimes you'll run into code like this when somebody's "decompiled" a program — variable names do not survive the compilation process so this is sort of the best a decompiler can do when reconstructing a C++ program. Of course it cannot really reconstruct a C++ program; it can only re-spell the flattened logic in C++ syntax. Oh well.
Addressing your example specifically, it's worth noting that all identifiers beginning with two underscores are reserved to the implementation (your compiler and standard library), so your program has undefined behaviour.
This question already has answers here:
Variable Naming Conventions in C++
(12 answers)
Closed 9 years ago.
In many examples of code that I've seen, they name their variable in a specific way.
E.g.
class obj
{
int mInt;
}
or
bool gTexture;
Questions.
Why do they name them in such way, and there are for sure more ways, I think...
How do you name them, and why?
Thank You
The m in mInt represents that the int is a member variable, while the g in gTexture denotes the variable being global.
This comes from Hungarian Notation.
http://en.wikipedia.org/wiki/Hungarian_notation
Naming is personally. To answer your second question, I don't use such a naming convention, and I append an underscore to class attributes.
Companies have often naming conventions. You may want to have alook at Google's naming conventions: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#General_Naming_Rules
The example you have given uses 'm' for member varibles and 'g' for globals. This is something that is used by some people. It makes it easy to see in a member function (when the function is a bit larger than a few lines, so you can't just look up at the top of the function to see the name of the parameters, local variables and so on), what is "local variable" and what affects "outside of the function".
If you work for a company, in a school or on an open source project, most likely, there is a coding standard that tells what the naming convention is. If it's your personal project, then decide on something you think works for you. The main point is that it's consistent. If not ALL member variables start with 'm', and not all global variables start with 'g', then it's pretty pointless to have it some places - just gives a false sense of security.
You haven't to follow a specific notation but it's cool if you do.
All is about clarity of your code, a variable without any upper case is truly less understandable than a variable with a good synthax. (At the first view, when you look quickly a part of code)
For a clear code, I can recommend the google's norme for c++ code : http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Why do they name them in such way, and there are for sure more ways, I think...
Generally it is difficult to understand other people's code; If enough time passes, it is difficult to understand your own code as well.
Because of this, software teams set up conventions to make sure the code their team writes is as similar as possible to the code they themselves would have written.
This refers to structuring code, used elements (interfaces, classes, namespaces, etc), naming functions and variables, what to document and in which format, and so on.
When done properly and consistently, it has a significant effect of shortening code maintenance time within a team.
There are a few known conventions, mostly from the conventions used in implementing large code bases and used libraries.
Java tends to use camelCaseNotation (start with small letter, use no underscores, capitalize each word).
MFC used the Hungarian notation, where variable names are prefixed with a few letters specifying scope and type of data (m_XXX for member variables, g_XXX for globals, s_XXX for statics, etc).
In particular the Hungarian convention can be gotten right (by using prefixes for semantic information) or horribly wrong (by using prefixes for syntactical information).
(MFC got it horribly wrong.)
ANSI C++ (and std:: namespace) tends to use small_letters_with_underscores for identifiers.
There are others and most software teams set up a convention that is a variation of one of the big ones.
How do you name them, and why?
These days I follow the ANSI C++ conventions, mostly because I want my code to integrate seamlessly with library code. I also think it looks simple and obvious (and this is very subjective).
I rarely use one letter variables (only when the meaning is clear) and prefer full words, to shortened ones.
Examples:
indexes: int index, line_index, col_index;
class names: class recordset; class task_details; etc.
http://en.wikipedia.org/wiki/Hungarian_notation
Not a real question. Everyone name them as they want to. You may read these guidelines, though: http://msdn.microsoft.com/en-us/library/vstudio/ms229045(v=vs.100).aspx
The MSDN documentation for the Microsoft-specific __if_exists statement says the following (emphasis added):
Apply the __if_exists statement to identifiers both inside or outside a class. Do not apply the __if_exists statement to local variables.
Unfortunately there is no explanation for why you should not apply this to local variables. It compiles fine and has the expected effect, so I'm wondering if anyone knows why they say not to do this. Is it a correctness issue, or a maintainability issue, or something else?
I realize that this is a Microsoft-specific feature and not portable, but let's assume for argument's sake that there's a good reason to use it.
EDIT: Some folks are curious why I'm doing this, so here's an explanation. I realize this is a dirty hack, so unless you have a good suggestion for a better way to do it, please don't bother pointing out that it's gross. It's the least-gross alternative we were able to find given the large size of the code base.
We have a large body of legacy code (millions of lines) that uses the Microsoft-specific __FUNCTION__ macro as part of an error logging package. A significant fraction of that code is now wrapped inside lambda functions so that we can catch structured exceptions (with __try/__except) and still use unwindable objects. Inside those lambda functions, __FUNCTION__ evaluates to something useless like `anonymous-namespace'::<lambda23>::operator(), which is not useful for anything. Our workaround for this is to define new __FUNCTION__-like macro which checks for the existence of an alternate local variable with the enclosing function name, using __if_exists. Due to how the macros work, we can easily switch to the new __FUNCTION__ substitute and easily define the alternate name variable without changing tons of code, so it's a reasonably clean solution given the limitations. That is, of course, assuming that it's valid to use __if_exists this way.
As I said above, I know it's a dirty hack, so please don't tell me how ugly it is unless you have good ideas on how to do it better.
I don't know for sure, but one guess is a local variable might be optimized away by compiler, and maybe not of course, which renders __if_exists test unrelieable.
And I also don't see the reason to do this for a local variable, you are in that specific scope, you know everything, why you want to test if a local variable exist?
__if_exists is a dirty old hack inside Visual C++, with severe implementation limitations as it was only intended for ATL.
Local variables are special because you can have two local variables with the same name:
void foo()
{
int i = 1;
{
int i = 2;
}
}
This means there's a more complicated datastructure inside the compiler to track them. __if_exists has to do a name lookup, which may not be correct for some types of nested scopes like this.
Another historical case is that in Visual C++, for wasn't correctly scoped:
void foo()
{
for (int i = 1; false; ) { }
__if_exists(i) // What do you expect? VC++ let i escape.
}
Just having an conversation with collegue at work how to declare a variables.
For me I already decided which style I prefer, but maybe I wrong.
"C" style - all variable at the begining of function.
If you want to know data type of variable, just look at the begining of function.
bool Foo()
{
PARAM* pParam = NULL;
bool rc;
while (true)
{
rc = GetParam(pParam);
... do something with pParam
}
}
"C++" style - declare variables as local as possible.
bool Foo()
{
while (true)
{
PARAM* pParam = NULL;
bool rc = GetParam(pParam);
... do something with pParam
}
}
What do you prefer?
Update
The question is regarding POD variables.
The second one. (C++ style)
There are at least two good reasons for this:
This allow you to apply the YAGNI principle in the code, as you only declare variable when you need them, as close as possible to their use. That make the code easier to understand quickly as you don't have to get back and forth in the function to understand it all. The type of each variable is the main information about the variable and is not always obvious in the varaible name. In short : the code is easier to read.
This allow better compiler optimizations (when possible). Read : http://www.tantalon.com/pete/cppopt/asyougo.htm#PostponeVariableDeclaration
If due to the language you are using you are required to declare variables at the top of the function then clearly you must do this.
If you have a choice then it makes more sense to declare variables where they are used. The rule of thumb I use is: Declare variables with the smallest scope that is required.
Reducing the scope of a variable prevents some types errors, for example where you accidentally use a variable outside of a loop that was intended only to be used inside the loop. Reducing the scope of the variable will allow the compiler to spot the error instead of having code that compiles but fails at runtime.
I prefer the "C++ style". Mainly because it allows RAII, which you do in both your examples for the bool variable.
Furthermore, having a tight scope for the variable provides the compile better oppertunities for optimizations.
This is probably a bit subjective.
I prefer as locally as possible because it makes it completely clear what scope is intended for the variable, and the compiler generates an error if you access it outside the intended useful scope.
This isn't a style issue. In C++, non-POD types will have their constructors called at the point of declaration and destructors called at the end of the scope. You have to be wise about selecting where to declare variables or you will cause unnecessary performance issues. For example, declaring a class variable inside a loop may not be the wisest idea since constructor/destructor will be called every iteration of the loop. But sometimes, declaring class variables at the top of the function may not be the best if there is a chance that variable doesn't get used at all (like a variable is only used inside some 'if' statement).
I prefer C style because the C++ style has one major flaw to me: in a dense function it is very hard on eyes to find the declaration/initialization of the variable. (No syntax highlighting was able yet to cope reliably and predictably with my C++ coding hazards habits.)
Though I do adhere to no style strictly: only key variables are put there and most smallish minor variables live within the block where they are needed (like bool rc in your example).
But all important key variables in my code inevitably end up being declared on the top. And if in a nested block I have too much local variables, that is the sign that I have to start thinking about splitting the code into smaller functions.
In my header, I have a prototype declaration like this:
void move(int, int);
I can omit the parameter names, that's how I'm used to it from C. I do that so that I don't have to keep the parameter names in sync - it's extremely confusing if they differ between prototype and implementation.
Right now, I'm documenting all of my code with Doxygen, and I decided to put all comments into the header. Now I have to refer to parameter names that are defined in the implementation but not in the header: I find that confusing.
/**
* Moves the entity to the specified point.
* #param x The x coordinate of the new position.
* #param y The y coordinate of the new position.
*/
void move(int, int);
In the generated Doxygen HTML, it is not easy to figure out which parameter is which. Of course, one could follow the same order here, but if one has many parameters, it is still confusing.
The alternative would be to duplicate parameter names and try to keep them in sync. However, some people don't encourage this approach, saying that header parameters should start with a double underscore so that the user of a method can not possibly use the same name (names starting with __ are disallowed in C++).
How do you do it?
It is a terrible idea to not name the parameters in the header if it is not clear what that parameter is for. The header should be the documentation for your code, so that someone trying to use it can avoid reading the implementation. As you found, it's pointless to document the parameters by name and then not tell the user which is which. That's not to say that they must match, but in the header they should be meaningful for the users of your code. In the implementation, choose the name that is best for you. E.g. it would be totally feasible to have:
.h:
void move(int x, int y);
.cpp:
void move(int deltaX, int deltaY)
{
...
The only times that it would make sense (if you care about other programmers using your code) to elide the parameter names is when it is bone crushingly obvious what that parameter does. E.g.
void SetNumPotatoes(int);
void EnableLights(bool);
void InitFoo(Foo&);
// but then...
T& GetItem(int); // probably obvious enough, but does typing 'index' kill you?
void DoSomething(bool, float, int); // someone using this will say, "WTF?"
Surely if "names starting with __ are disallowed in C++", you shouldn't be using them in prototypes either :-) *a
I see two ways to do it.
One, you can ensure that the order of parameters in your comments always matches the order in your prototype.
Or, two, you could actually put the real names in your prototypes as well.
Myself, I prefer the second approach since I like to be able to tell what parameters are passed in, even if the function has no comments on it (or worse, the comments get out of date). This is far easier with a prototype like:
void move(int xcoord, int ycoord);
than it is with:
void move(int, int);
In some environments, we've even gone so far as to have the build process ensure that all function prototypes have identically named parameters as the function definition.
*a) These identifiers are actually not for the use of regular programs. Section 17.6.3.3.2 of cpp0x (but this restriction has been around for quite a while in both C and C++) states:
Certain sets of names and function signatures are always reserved to the implementation:
Each name that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
In other words, don't use them for your own purposes.
They don't need to match, but I find parameter names to be invaluable documentation. I hate it when they're missing. I like in-code documentation far better than documentation in comments.
And the advice at the end of that link is really silly. Parameter names are nothing special as far as being in danger of being redefined by a #define. Function names and practically any other identifier in your header are in danger as well. That's why the naming convention of using ALL_UPPERCASE for your #define names exists.
No, make the names match in your implementation and in your header, even though the compiler will be fine if they don't. And if they don't match, fix it so they do. They provide excellent documentation and they will be confusing if they don't match.
WRONG documentation/parameter names is ALWAYS WORSE than NO documentation/parameter names. I'm not saying you don't need documentation or parameter names - I'm saying that you better keep up with them! That's why they pay us the big $$$ :-D
I always use parameter names both in header and in implementation. It is not difficult to keep them in sync - when I change the function parameters, I usually:
* Add/remove a parameter (no problem here - you have to sync it even if you didn't use parameter names)
* Change the order to be more logical (again, even the types have to be synced)
The advantage of having the parameter names in both prototype and implementation is that it helps the user - he can see the names in his IDE code completion, he doesn't have to navigate to the definition (which might be unavailable) to find out the parameter names. Another good reason for sticking to this practice is your Doxygen problem.
I also don't really see the point of using double underscores in prototype parameters. Yes, #defines are evil, but double underscores are reserved for compiler writers. Unless you write a standard header for your compiler, you should avoid it.
C and C++ are the same in this regard. The prototype names don't need to match up… that's why they may be omitted.
Pick names for the parameters; when you put them in Doxygen they become part of your API. You can change them later, but you're changing the API; you can change them in the implementation as well but then it won't match the spec as cleanly.
Do not use a double underscore, even for "ignored" identifiers. The compiler may define anything beginning with double underscore to mean anything, potentially causing a syntax error. Such words aren't just forbidden for names of in-scope variables, they are completely toxic.
If the header file belongs to an OEM library which is expected to be used by many third party vendors, inquisitive developers (such as those belonging to SO), will most certainly explore the header files in addition to the supplied documentation, given the fact that most of the time documentation is either very bad or lags significantly behind the code.
Therefore, I would say, the issues cited about the naming the parameters could be a development time pain, but is almost certainly a customer's delight.
What is protype declaration is that you are informing compiler that this type of function is going to come with this arguments and with this data types. So compiler will make arrangemnts for that type of arguments.
hence proto data type and number of arguments should match with the actual definition and run time usage.
Otherwise it will give an run time error.