Consider this in the (possibly nested) scope of a method (function, block, etc.):
int _ = 42;
Are there any technical reasons to avoid a local variable named _?
Some guidance, for the purpose of this question:
I know _ generally prefixes Objective-C instance variables.
Leave that aside. Commentary on other clashes with convention welcomed.
I like pretty code too, but statements of taste or pure opinion (e.g. "It's {confusing, unreadable, unmaintainable}") are strongly discouraged here†.
I'm primarily interested in answering this for Objective-C, but answers
related to C or C++ are also encouraged.
† Buy me a pint, and you can tell me all about it. :)
C99 §7.1.3 says that all identifiers beginning with at least one underscore are reserved for use by the implementation, as file-scope identifiers only.1 _ is an identifier that begins with at least one underscore, so you're not supposed to define it in any way at file scope.2
However, as a local variable name, _ is fair game for the application programmer. Only identifiers beginning with either two underscores, or an underscore and then an uppercase letter, are reserved unconditionally.
These rules are honored more in the breach than the observance, as the footnotes demonstrate.
1 Yes, that means the very common practice of starting "internal use only" function names with _ followed by a lowercase letter is technically a conformance violation.
2 GNU gettext is a prominent third-party library that breaks this rule; the programmer is encouraged to #define _(x) gettext(x) as shorthand.
To answer your question simply - no, there aren't any technical reasons to avoid it. Lots of other reasons though.
Related
In large codebases, it might be impossible for the maintainer/project-owner to review and audit every line of code. In C++, some identifiers are reserved (according to the standard) and prohibiting the definition of reserved identifiers seems reasonable.
According to Identifiers - cppreference.com:
the identifiers with a double underscore anywhere are reserved;
the identifiers that begin with an underscore followed by an uppercase letter are reserved;
the identifiers that begin with an underscore are reserved in the global namespace.
Is there tooling to enforce this guideline (prohibit the use of reserved identifiers)?
For instance, is it possible (through GCC, Clang, clang-tidy, or some other compiler or linter) to get code like the following snippet to error:
auto __destination = cv::Mat3f(1, 1);
cv::cvtColor(source, __destination, cv::ColorConversionCodes::COLOR_HSV2RGB);
auto result = __destination.at<cv::Vec3f>(0, 0);
I know I can either hack around this by testing some regular expressions against the codebase or even solve it decently by parsing the C++ code into a parse tree and then validating all identifiers, but I am interested in knowing whether or not there is already something that does this.
I would be interested in forbidding even the use of already defined variables starting with a double underscore as it could be a hack exploiting a GCC leaky abstraction, for instance.
Clang has this feature starting from version 13 with -Wreserved-identifier flag (link).
GCC doesn't implement such feature yet (as in March 2022).
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.
I have read the document about naming rule of C++, they seems to be usable names.
However, in practice, when I tried to create a variable/enum with a name like iter, yes, no, out, i, Error, etc. , Visual Studio will strangely use italic font for them.
I can only guess that they are reserved for special thing, and IDE (e.g. refactoring/rename process) might act strangely if I use such names.
Is it safe to use those names in practice? Am I just too panic?
Sorry if it is too newbie or an inappropriate question.
I doubt about it for a few weeks but too afraid to ask.
These names are valid and will not cause any "harm", the standard only says:
Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) 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.
Which means that all your names are fine to use in user-code. Visual Studio might just have a thing for these names as i and iter are usually used in looping.
These names are not reserved in standard C++, as explained by Rick Astley. An implementation may choose to accept additional reserved words to provide language extensions, such as ref class in C++/CLI. In some cases, such as with ref class, where ref is a contextual keyword, these extensions only make otherwise ill-formed programs well-formed in the scope of the extended language. In other cases, an otherwise well-formed program may change its meaning or become ill-formed. In the former case, the implementation is still conforming to the C++ standard, as long as it issues all mandatory diagnostics; in the latter case, it is certainly not conforming.
It is considered good practice to make the latter kind of extensions optional e.g. using a command line option, so that the implementation still has a mode in which it is fully standards compliant. My immediate guess is that VC++ in fact does allow you to write well-formed programs containing yes, no, i, iter which will behave as required by the standard (implementation bugs notwithstanding).
The IDE is a different beast, though. It is considered to be outside of the scope of the C++ standard, and might discourage or even stop you from writing perfectly well-formed code. That would still be a quality of implementation issue, or an issue of customer satisfaction, if you will.
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
Simply: why is the nullptr keyword in the C++0X/C++11 standard lowercase, whereas its close companion NULL is uppercase? I do realise that the two adhere to different standards; nullptr is a keyword, whereas NULL is a macro. But since they will be used in similar situations, wouldn't it be clearer for new users if they followed the same convention?
(Not that it's that much of a bother to remember - I'm just curious about the design decision.)
NULL is a macro, and a common convention is that macros are uppercase, while nullptr is not a macro but a keyword and is lower case as all other keywords.
But since they will be used in similar situations, wouln't it be clearer for new users if they followed the same convention?
The potential source of confusion would change and someone else would be asking why a keyword is upper case (assuming NULLPTR, as null would break backwards compatibility in the language)
Lower case definitely fits better with general naming conventions of C++. Using all caps wouldn't do anything to help the new users at all.
And I don't believe it would actually be all that helpful to the old users who grew up with using NULL in C (or were in the cap of C++ users who used NULL instead of 0).
Certainly, I don't see anything that would amount to a justification of breaking the naming convention in this case.
Okay I am editing my original answer because I misread the question. I am going to claim that it is lowercase for the same reason the true and false keywords are lowercase.