Confused about naming a standard identifier

Reading the book, he says that these two are conditional conventions:

  • do not use underscore in identifiers
  • the identifier should not start with an uppercase letter

But in many places I see, especially in the properties, that the author does not follow this, for example:

private int x

and

public int X ..

Same thing with underscore .. sometimes it uses _x and X for properties.

What is the correct naming convention, please?

+4
source share
6 answers

The rules are not the same for all identifiers. And there are many standards around, all is well if they are used consistently.

What I remember from MS recommendations:

  • class (type) and public user names use PascalCasing
  • private members, local vars and parameters use camelCasing

But camelCasing just means “don't start with capital”, field , _field , mField and m_field all qualify.

+6
source

In addition to all the other great answers, I will add that it is bad practice to run an identifier with two stands. The C # specification says that we reserve the right for things starting with two substrates to have special meanings. This is our escape, so if we really need to, we can add new features to the language without disturbing anyone. Or we can use methods that start with two substructures as methods for generating a special purpose compiler.

+4
source

As others have noted, naming conventions differ between developers and teams. The only thing that really matters is that you are consistent.

If you are looking for recommendations to follow, Microsoft is publishing a set of generic naming conventions for the .NET Framework. They are somewhat scattered around their website, but this page is a good start.

The executive summary is as follows:

  • You must use the Pascal shell for all public member names, type and namespace (e.g. BackColor )
  • You should use camel shell for parameter names and local variables (e.g. BackColor ).

In addition, you will often see private variables (in particular, those that have the corresponding public property), named with an underscore prefix (for example, _backColor ). Another convention adds m_ .

+3
source

I'm not quite sure that there is a proper way of naming identifiers. Some people use underscores to denote member variables; some use the m_ prefix. Some use an underscore to indicate variables that have been passed as parameters.

As for capital letters, some use them, some do not use, and some use the "camel case", where the first letter is non-capital, but the following "words", for example:

 thisIsCamelCase 

What matters is that you are consistent. If you decide to use _ as a prefix for members, make sure all members have this agreement.

Personally, I use _ as a prefix for parameters and m_ as a prefix for members.

 public class Vector { private float m_X; private float m_Y; private float m_Z; public Vector(float _x, float _y, float _z) { m_X = _x; m_Y = _y; m_Z = _z; } // eo ctor } // eo class Vector 

It definitely sounds quirky that your book preaches this "never again never", and then quickly ignores his own advice.

+2
source

It depends on the taste or team in which you work.

variables never begin with a capital letter or number. You can use the underscore, which many developers prefer because all of their field members are grouped in a visual studio using intellisense.

 private int _number; private int _Number; 

Most of them prefer an underscore and an uppercase letter, because when you write the usual variable name, you use camelCaseNotation.

You would write like this:

 private int number; 

but since you use an underscore, the first char is an underscore, and the next char will be uppercase (see camelCaseNotation) for example:

 private int _Number; 

For properties, you simply capitalize them without prefixes:

 public int Number { get; set; } 

For parameters, you can use the same underscore prefix as field members if you like it:

 private int _Number; public MyClass(int _Number) { this._Number = _Number; } 

There is no right or wrong, just try following the language guidelines and adapt to the team you're working with. Discuss with your team what you will use, and they will all use the same thing, which makes the code much better to read.

On notation of m_ notation or Hungarian notation (sName, iNumber, ...), this is a bit "old", try to avoid this (most C / C ++ programmers use those that are new to C #).

+1
source

I would add that its general use of only capital letters for constants

 public const int STATUS_OK = 0; 
0
source

Source: https://habr.com/ru/post/1338620/


All Articles