I remember I read some neat code a few years ago. At that time, I just read it roughly and forgot all the contents. In order to ensure that I won’t forget the contents again, I specially made some notes for easy reference

conclusion

As a poor English code farmers, may be the most head-scratching thing is named. But this is a problem we have to face every day, how to take a good name? Through reading this book, I think the following points need to be met.

  1. Express meaning clearly enough to be clear and unambiguous.
  2. Keep them short, and if short names don’t make sense, lengthen them.
  3. No useless prefixes, context
  4. Make a clear distinction between names
  5. English words or combinations of words, not made-up words or misspelled words.

The following are specific explanations of the above conclusions.

Worthy of the name

  1. As soon as you find a better name, replace it
  2. If a name needs comments to complement it, it’s not worth the name
  3. Choosing a name that reflects the original meaning makes it easier to understand and modify the code

1 and 2 are mainly used to illustrate that naming should be clear.

To avoid misleading

  1. Do not use accountList to refer to a group of accounts unless it is truly a List
  2. Beware of names that are less different. This distinction is too costly
  3. Avoid using lowercase l and big O as variable names, which can be misleading as numbers 1 and 0

2 and 3 mainly mean that there should be a clear distinction between names.

Make meaningful distinctions

  1. Add a number series (A1, A2, A3…) after the name. It’s not enough, it’s misleading, it doesn’t provide the right information
  2. Do not substitute spelling errors for distinguishing existing names.
  3. Nonsense is a meaningless distinction. For example, in a project,the Product class, ProductData and ProductInfo have different names but no different meanings. Info and Data are just like a,an and the, which are nonsense with confused meanings
  4. The word Variable should never appear in a Variable name, and the word Table should never appear in a Table name

Use the read name

  1. Don’t use silly made-up words, use proper English words, and try not to abbreviate them as they might mean something else

Use searchable names

  1. The problem with single-letter and numeric constants is that they are hard to find in a lot of code, but if you define a long name representation, it is easier to search. This is also an object-oriented idea – encapsulation.
  2. The long names are better than the short ones, and the searched names are better than the ones you make
  3. Single letters are used only in local variables for short methods, and the name length should correspond to the scope size to facilitate searching

Avoid coding

  1. Use Hungarian notation
  2. Leaving out member prefixes, because people now ignore prefixes and just look at the meaningful part of the name, and the more you read the code, the less you see prefixes, and eventually the prefixes become junk, and they’re junk, and you just leave them out
  3. Instead of using the prefix I to indicate that the class is an interface class, use the suffix Impl to denote the implementation class

Avoid mental mapping

  1. Readers should not be allowed to translate your written names in their heads into names they know well.
  2. A single letter is not a good choice, the reader must map it into a real concept in his mind
  3. The difference between a smart programmer and a professional programmer is this
  • Professional programmers know, and clarity is king.
  • Professional programmers use their skills to write code that other people can understand

The name of the class

  1. Use nouns or noun phrases
  2. Avoid using class names like Manager, Processor,Data, or Info.

The method name

  1. A verb or phrasal verb

Don’t dress up as lovely

  1. Better clarity than fun
  2. Programmers are very strict and may not get cute points
  3. Being cute often involves using colloquial or slang expressions
  4. I mean it, I mean it

Each concept corresponds to a word

Pick a word for each abstraction and stick to it. If you have cotrollers, managers, and drivers in the same heap of code, it can get confusing

No puns

  1. Code writers should try to write code that is easy to understand, so that others can see it at a glance, and not have to suffer from painstaking research
  2. Paperback books should be used in a popular way, not in a scholarly way

Use the solution domain name

Only programmers can read your code, albeit in computer science terms, algorithm names, pattern names, mathematical terms.

Use names derived from the domain in question

  1. One of the jobs of some programmers and designers is to separate the concepts of solution domain and problem domain

Add meaningful context

However, it is recommended to provide context to the reader through a well-named class, function, or name control. If not, add a prefix to the name to provide context for the reader.

Don’t add useless contexts

If you add a prefix to all of your classes, you don’t add anything, and you omit everything you don’t add.

The last

Use modern tools to get at the details so you can focus on writing code like words, or at least like tables and data structures

Coding standards

  1. Variable names without m or _ are useless
  2. The implementation class is denoted by the suffix Impl

Delivery Address:

Clean code