48
I recognize that it is common for each language to use a pattern to compose its identifiers (variables, constants, objects, controls etc).
In the case of C#, what would be the best practices regarding upper/lower case, size and use of special characters?
49
PascalCase. It depends on whether you are considering it closer to being private or closer to being public.| Pascalcase | camelCase |
|---|---|
| Classes | Local variables |
| Assembly | Method parameters |
| Classes | Private and protected camps |
| Structs | |
| Intefaces (always with the I before the names) | |
| Delegates | |
| Enums | |
| Methods | |
| Estates | |
| Public camps | |
| Events |
Norma452.b001.DoThis() may be great as a generalized example but has no meaning to the code. The most important thing is give significant names. Especially don’t give names that mean anything else, even if eventually. Ex.: string nonBlank = " ";Counter is an accountant, Count is a count and TotalCount is the count totalizer. Be as specific as possible. SalveNome() is better than SalveCampo() unless the second saves any field to be specified.Ftp, UI, IO, DB, PK, AlgumaCoisaInfo, Config, ValorIcms, Id, Args, ex (for what can only be an exception), i for loops (i has an obvious meaning for any programmer), temp or even tmp (but do not use both). In local variables the abbreviation is not so problematic if it does not create incomprehensible mnemonics. It’s best to avoid them, but you don’t have to exaggerate. It becomes a problem if everything is abbreviated or not able to understand the intention of the variable by any programmer with minimal experience. Don’t ask me why it’s better Pascalcase in Ftp but ALLCAPS in UI, IO, etc. I imagine it is the fact that there are only two letters in the acronym. Already Id is one word. Some prefer ID. I don’t, but I maintain a pattern.m_. Underlining can be used for an irrelevant parameter in a lambda. Ex.: (_, __) => FazAlgo(); when you know you need to receive two arguments but they will not be used in your execution.TextBox with descrição is not Hungarian notation, it is important to understand what that identifier is. Already a method GetInt() may be since it is not saying what is taking and yes the kind of what is taking, the intention is this, it is not a simple feature. carArray probably Hungarian, prefer to carros.value or valor, item, etc..Begin comes before a End, not to be confused as a Start that comes before a Stop and a Initiate before Finish, one Open before Close, Lock before Unlock, Block and Deblock, Head and Tail, Header and Footer, Before and After, Read and Write, Input and Output, First and Last, Previous and Next, Increment and Decrement, Enter and Leave, Add and Remove, Create and Destroy, Insert and Delete, Show and Hide, Suspend and Resume, Top and Bottom, etc. Others are more complicated to state or depend on context. Do house with Cancel? And Go has to do with Quit? Or the reverse between the above terms? And what about the use Run, Execute, Perform, Abort?. It is good to learn before using. Understand the difference between Find, Seek, Search, Lookup, Scan, Traverse, Locate, Select, Query, Pick, Trace, GetAbcXxx and similar and its translations. Do not stick to these words, they are just examples of similar concepts that can be defined more precisely with the correct word. Calcule is different from Pegue which is different from Leia. A property TemPedidos is very different from a method VerifiqueExistênciaDePedidos(). Understand the difference between Increment, Add, Plus and Accumulate. Choose names that identify if there will be side effect, mutation of the object or not.!family.hasNoChildren. Be affirmative.And or E There’s a chance something’s wrong.Color color = Color.Red;). This should only be avoided if the variable name does not quite indicate what it is doing there. Contextual meaning can be lost when adopting this pattern (maybe better Color statusColor = Color.Red;).is, can, has, isThere (some prefer to use only the has), allow (which may be the same as can). Or in English é or eh, está or estah (usually followed by a verb in the participle or adjective), pode (usually followed by a verb in the infinitive), tem (probably followed by a noun), Existe (followed by a noun). The plural can be used, or another conjugation, e.g. .: foiTentado. And remember that an enumeration usually gives more semantics than a boolean, even when there are only two states. The Boolean semantics is just to say whether it is true or false, do not use for other things that have only two states.EventArgs for the parameter that will receive the event arguments. This makes clear the intent of this parameter. Probably this parameter will be a subclass type of the EventArgs.able or ável. In some projects abstract classes usually carry the suffix Base. I have my doubts whether this is consistent, as far as I know is not recommended by Microsoft. Using the base class name as part of the name of the new derived class is usually a good option, but care must be taken to avoid exaggerations and long names that end up not identifying well what the class is.Extension. Some people think Ext is sufficient. In some cases a normal static class may have the suffix Utility or Helper but these classes should be avoided. If it has any well-defined function the suffix is unnecessary. This is reflected in Math and Console.[Flags]. And don’t use a prefix or suffix Enum in the name. Redundancies of this kind in other things, especially in column names in databases is one of the biggest abuses I see in nomenclature.Exception to avoid confusion. This way makes clear to what should be used.Attribute in its definition. The compiler himself knows that the use of attributes does not use the suffix, that is, he knows unequivocally that it is an attribute and that the original name needs a suffix. Not putting the suffix in the statement can cause problems, as well as putting in use.Delegate. Some people find it unnecessary. Microsoft habitually use suffix but seems to be "as necessary" as the suffix Enum in an enumeration. Prefer to use a lambda and don’t worry about it :).T, U, K, V). If you have a good reason you can use more meaningful words but don’t use names that can be confused with existing types (you never know when it will cause confusion), especially don’t use Type to avoid confusion with the type Type. If using a more descriptive name use the prefix T. Ex.: TKey and TValue.Get or Pegue or Compute, etc. There are those who use PegarXXX() or CalcularXXX that apparently would be the infinitive. I do not know if this is an error by ignorance or there is some reason for conscious choice. I believe more in the first.Async should always be used in methods that have this feature. It is important to identify a method with such a special feature and helps to distinguish it from the synchronous version.Before or After or similar names. If the event should perform the action the name must be in the infinitive. Ex.: Deleting, Deleted and Delete. Event handlers must have the prefix on. There are controversies whether there should be the aportuguese form for on.NotSelected.Line.GetLength() à Line.GetLineLength().using when using several members of a namespace in larger files (most cases).ServiceModel à Service.Model.XmlDocument within the NS Xml is not a redundant exaggeration.AlgumaCoisaAsync, FazAlgoEx.Most of these recommendations were defined by language creators/framework to facilitate and standardize the understanding of the code by all. The most important thing is to maintain consistency between a team. But if you think your code might end up being shared with people you don’t know (here for example) it’s best to try to follow universal standards.
Of course, some conventions help more than others and what helps most is to maintain clarity than what you are trying to indicate there. This is usually only easy to do when you fully master the problem. Naming something eventually is hard enough, imagine naming thousands of things you don’t master in a few days of work.
These conventions facilitate the reading and maintenance of the project. Indirectly thinking about this helps to understand what you are doing. But try to understand the motivations for the recommendation, this can help you more, can help your code be better written beyond the nomenclature.
Obviously I haven’t made a full list of conventions and much less explained each one.
AP’s answer already gave good indications of what should be done to try to achieve a better result, I tried to stick to some guidelines that I found and that I follow or that you could follow.
I disagree a little bit with taking care of names that can impact data traffic. This should not be a concern. If it is important (usually it is not) it is best to create a post-code way to reduce the size. The question of underline It’s not the official recommendation, but of course there’s no such thing as right and wrong at conventions, I’m just pointing that out. Ubiquitous language can be good if you don’t misunderstand what this is, don’t overdo it. It is usually difficult to find universal consensus of what is more ubiquitous. I honestly do not know if it is better nomeTextBox or textBoxNome (this is a TextBox of Nome or is a Nome encapsulated in a TextBox?), then pick one and keep the consistency.
As already said you can use tools to help force these patterns, but only a small part is possible. You can take a look at the rules existing in Stylecop and can create their own.
Always remember that if there is a good reason, do not follow the recommendation. Know that some slips will be punished more intensely than others. And the main thing is, no convention is mandatory. Don’t you like it? Do you think it’s problematic? Is there a good reason not to follow at a certain point? Use another way. Conventions and guides are like good practices, only good when you know when not to follow.
In the There’s only so many answers on the subject on an individual basis.
I write more on the subject in that reply.
I may have missed something, comment.
24
Generally speaking, for C#, the default Camel case is widely used. Summarizing, in this pattern, names are composed by simply uniting them without any sort of separator, such as underscore (_). What helps differentiate the words is the FatoDeCadaUmaIniciarComMaiúscula. In addition, choosing the name of the element can contribute - and greatly - to the understanding of your code by the team (and by yourself, when returning after a few months for an eventual maintenance). Below some considerations that may facilitate when choosing the name of your identifiers:
First, choose a name that gives meaning to that element. Read the code again, as if it were a text in Portuguese and try to evaluate if the sentence you just read makes sense, that is, if it is coherent and does not induce the reader to any kind of ambiguity. If you don’t remember what a variable is for (x is a bad name), is likely to have chosen the wrong name.
Generally, acronyms and abbreviations tend to hinder the understanding of the code, unless they are widely used by everyone in the team and in the company. An increasingly disused pattern, the hungarian notation, provides for the use of abbreviations for naming controls and to this day many people use it to give names to database elements. So a text box could be called txtNome. By opting for more eloquent language, the abbreviation would be replaced by textBoxNome.
Under the influence of Eric Evans, in his book Domain Driven Design, there is a tendency to assign names that express before business and then technology. For a developer this represents a challenge, because we express most of the time using an essentially technical language and full of own terms. Focusing on the business, the txtNome control would be called nomeTextBox, for example. Ubiquitous language is considered the one that all involved speak, which is present in the everyday vocabulary of the organization and facilitates the understanding of a concept by all.
In the pattern Camelcase there is a common distinction for the first initial:
SituacaoVenda. For Constants and Enumerators also.notaFiscal, contadorItemNotaFiscal.The limit for the size of an identifier’s name is common sense only, there is no limitation imposed by the framework. Thus, very long names can take up too much screen space and disturb reading. It is also worth remembering that, for names of controls on the web (in the view itself), the issue of size can impact data traffic, since each character represents a byte.
In C#, it is common to use underscore (underline, underscore) to initialize private fields, also known as attributes. They are those elements declared in the class scope and therefore available for all methods of this class. Thus, a field to represent the client repository could be called _clienteRepositorio.
Every language has its reserved words (key words). In C# it is possible to use arroba (@) if it is very necessary for a variable to be called class, for example (@class).
Visual Studio itself suggests names for controls using these patterns. If you create a menu item with the Clients description, the IDE will suggest that the respective control name be clientsMenuItem, for example.
Another tool that implements these practices is Resharper from Jetbrains. This tool already suggests a much more comprehensive set of good practices, highlighting in the code the nomenclature that escapes the standard.
Very complete answer. Congratulations.
@Guilhermejsantos and my answer is complete? :)
4
There is a pattern of naming variables and facilitates coding
Methods => Uppercase letter in the first letter example: private void Getcadastrarusuario()
Propreties => Letter Uppercase in the first letter example: public String Name { set; get; }
Event => Uppercase letter in first letter example: public Eventhandler Onchange;
Global Variables in Class Scope => Use '_' before the example variable name: int _variableEmplo = 0;
Internal Variables: => example: int value = 0;
Obs: When referring to a layout item through C# it is important to put the example : this.Buttonsave , because it makes it easy to identify where this variable comes from.
Browser other questions tagged c# encoding-style nomenclature
You are not signed in. Login or sign up in order to post.
"Try to use a more fluent way to give understanding to what you want but don’t overdo it. Try to use a language that is appropriate to the domain being developed for that specific task." - I think this is paramount, I believe it is the most that can facilitate the understanding of the code.
– Vítor Neil Avelino
Can you tell me if it’s better to use
_(underline) at the beginning of a private field? I get very confused, I see codes with it, others do not. VS also confuses me, when it creates the private fields and assigns the value from the constructor parameters, it does not use the_, but when is it to convert to a complete property, I think that’s how it’s there, it uses =/– Vinícius Lima
@Viníciusfile you can use, but it is not the standard adopts, there is no advantage in it if you adopt the other standards. Who does it does not follow the standard, including Visual Studio. It has bad things in it and in the documentation.
– Maniero
Excellent answer!! It should be as accepted.
– SUR1C4T3