Fables for the night - Good names as the key to success

Good day to all.

“As you call a boat, so it will float” is a well-known well-known phrase that fits well with functions, variables, classes.

How many times have you read a stranger (and sometimes your code, I repent, it happened like this with my own code) and dealt with the written mess. The purpose of variables, functions, or even classes is not intuitive.
It would seem that there is a variable, there is its name, but its purpose is not clear.
')
for example

enum Dates{
GET_FIRST,
GET_SECOND,
GET_BOTH,
None
}



Think about what this enam does in your code. It seems that the name of the listing is clear that the matter is related to dates. Two dates can be passed to the method, and you need to select one of them. Or maybe you need to take into account only certain dates, the first and second of the list. And maybe what else, maybe a lot of opinions.
In this case, look for a place where this code is used.

Boolean IsInRange( DateTime date1, DateTime date2, Dates pDates) {
if (pDates==Dates.GET_BOTH) {
return date1 <= myDate && myDate <= date2;
}
if (pDates==Dates.GET_FIRST) {
return date1 <= myDate && myDate < date2;
}
if (pDates==Dates.GET_SECOND) {
return date1 < myDate && myDate <= date2;
}
return date1 < myDate && myDate < date2;
}



And only then can it be understood that Yen determines whether to take the left and right borders into account.
But if, to understand the meaning of the object, you begin to delve into the code where it is used, then the name does not reflect the essence of the purpose. This is a bad name .
One could call it simpler:

enum DateIntervals{
Open,
Closed,
OpenLeft,
OpenRight
}


In this case, it is unlikely that you will have to climb on the code, looking for places of use of enam - his name, and so it says about its nature.

Comments
Comments are a sign that the name does not reflect the essence. Most likely, you should think about the name of the function, rather than a good comment.
I remember I had a bizik, to write comments to anything and everything was lazy, but I tried. Even where it was clear. But for the most part it did not benefit, but uh, hemorrhoids - oh yeah. So, write good names - it really saves time. There are no boundaries for perfection. It happens 5 times to rename, until you say - "here, this is it"

Pronounced names.

• GetPCF
• Getyyyy
• Getnn

The pronunciation is not so hot in these names. But the essence and even more so. The second name can be pronounced as - GetUayUaiUayUai. - It sounds like, God, why, oh why ...
And if a colleague asks which function is responsible for this or that operation, the pronunciation will not be completely clear, and it is also not entirely clear how it is written as a result.

Prefixes
During the absence of powerful development environments (everything is relative, of course), prefixes were adopted.

variable names at the beginning must contain a prefix that corresponds to a particular data type and is written in small letters. The name itself begins with a capital letter.
Prefix Data Type

• a array
• b bool boolean integer (one byte)
• by BYTE unsigned integer
• c character (one byte)
• C class
• d number with double precision (double)
• ....

Even now there is something similar. Do not mess with it. It is better to name a logical variable, rather than drag prefixes.

How long should the name be?
If the block of using a variable is limited to 3 lines, then there is not much point in calling the variable as firstIndexInUserCollection. The length of the name is directly proportional to the length of the block. The bigger the block, the bigger the name.

Function names
Public functions as a rule should have a short concise name (ideally, of course). Otherwise, every appeal from the outside will be very weighty. Private functions, on the contrary, can be accompanied by a long name that describes the purpose of its purpose.

Summarizing:

• Use names that express your intention. Then it will save a lot of time.
• Follow the comments, as a rule it is a sign of the need for a little refactoring.
• The name should be easy to pronounce.
• Do not insert suffixes and prefixes that are clear only to you.
• For functions, use names derived from the verb + noun / adjective
• Avoid misinformation - the function must do what comes from its name, otherwise it turns into a permanent memory of what the function does.
• Base classes must have short names. Each successor usually adds a word. And the heirs are still heirs. That can get a long paravoz

Happy codding.