"Go" writing high-quality Code 157 recommendations for improving C # Programs--recommendation 142: Always provide meaningful naming

Recommendation 142: Always provide meaningful naming

Never give your code a meaningless name unless you have a special prototype.

Afraid of needing too long a name to provide enough meaning? Do not be afraid, in fact, we are more mind is in the code when the appearance of a itemp.

A name such as int I can only appear in loops (such as for loops), except that we cannot find any reason to make such a meaningless name elsewhere in the code.

For example, the following naming is a good example:

        PrivateCultureInfo m_currentculture; PrivateCultureInfo m_currentuiculture; Private intM_managedthreadid; Private stringM_name; Private intm_priority;  Public Static intGetdomainid () {returnGetDomain ().        GetId (); }         Public Override intGetHashCode () {return  This. M_managedthreadid; }        Private extern BOOLJoininternal (intmillisecondstimeout);

We can see that each name expresses itself with meaning. One obvious benefit of good naming is that we can even reduce most of the code comments.

The bad name is as follows:

        int Theid;         int GetID (intint  b)        {            int  iTemp;             // omitted            return iTemp;        }

In this case, the field variable Theid indicates that the reader does not know what the developer is saying when he sees such a name. The parameters A and B of the GetID method are also unknown, and the caller does not know what value should be passed in at all. The internal itemp is equally bad and time is long, even if the developer himself forgets the meaning of the variable that was originally set.

Turn from: 157 recommendations for writing high-quality code to improve C # programs Minjia

"Go" writing high-quality Code 157 recommendations for improving C # Programs--recommendation 142: Always provide meaningful naming