The way to clean code (1)

The way to clean code (1)

2017-11-07 to 2017-11-08

foreword

Why would I want to buy this book? ? The reason is vague, but very simple - for more concise and beautiful code. However, concise and beautiful code is always rare. At least in some of the projects I have completed, neither I nor my teammates have a clear understanding of the cleanliness and specifications of the code, which is also the status quo that I hate. As a quasi-programmer, I think it's time to change all that. It's time to change!

Chapter 0 Written by myself

The following major titles are the original titles, while the subtitles have the original texts, and some are summed up by myself. Of course, to a large extent borrowed from the original texts. If there is anything wrong, please correct me.

Chapter 1 Clean Code

Preface to Chapter 1: Read this book for two reasons: first, you are a programmer; second, you want to be a better programmer. very good. We need better programmers.

1.1 Neat and cluttered

The first chapter doesn't go too deep, but it instills in us the "we need clean code" mentality. The code we need should be clean code. Maybe sometimes in order to catch up with work, we need to produce a lot of code faster, but we have to keep in mind that the code needs to be kept clean at all times, otherwise the messy code will only greatly reduce your efficiency.
Maybe you have had this experience too: I will change this code when I come back when I have time. nonexistent! ! It's not a question of whether you are free or not coming back. It is very likely that you have long since forgotten that you rushed to write a piece of junk code or have long forgotten what the thinking was at that time, because you wrote it, IMHO. . Still don't say it. Anyway, when I saw this paragraph, I really laughed, as if I saw what X_X
said when I was in the race a few months ago. After reading this book, we joined Martin's clean code group . Gang rules: keep the camp cleaner than when you came .

Chapter 2 Meaningful Naming

This chapter mainly talks about our most common naming. Often our subjective randomness will make us ignore the importance of an excellent naming. Anyway, after reading this chapter, I feel that Martin gave me a head-scratching drink, and I feel good.

2.1 True to its name

There is a lot of content written, in fact, to sum up: no matter the variable name or the method name, you should try to be able to see what it is used for at a glance. For example int d, without looking at the context, you don't know what it is, but when you write int elapsedTimeInDaysit you know it's elapsed time, obviously this is what the name really does. Of course, like some state values ​​1, 2, 3, 4, etc., you can give them some simple and clear names, such as FLAGGED and so on.
My understanding is that a variable or function name that people can understand without reading comments is an extremely good naming! !

2.2 Avoid misleading and make meaningful distinctions

It was originally two chapters, but I put them together. Because I feel that the two are related, and it can even be said that they are talking about the same thing.
To avoid misleading you can actually follow the following points:
- Don't use words that have special meaning to the programmer like List
- Don't use names with little difference
- Don't use the damn l and o and 0 and 1 and O

The first point is very clear, the second point gives an example of XYZContrillerForEfficientHandlingOfStrings and XYZContrillerForEfficientStorageOfStrings... There must be nothing to say. The third point, uh, figure it out for yourself. .
Meaningful distinctions note the following points:
- Avoid naming series of numbers, such as a1, a2...
- Don't talk nonsense

For the first point, choose a good name. . Don't talk nonsense, just like a, an and the, they are nonsense in many cases, and adding info or data after the variable does not seem to be of any use =.=
Summarize, avoid ambiguity, write clearly, Stop talking nonsense. .

2.3 Use names that are readable and searchable

How to say the name that can be read is to write the complete word as much as possible, and try to use the more common abbreviations. In fact, it can be understood in this way, don't name it with some abbreviations you create or think, otherwise it's holy shit!
Searchable names are more commonly used in variable naming. For example, I want to find the number 5. Using the search tool, it is estimated that it will take half a day to find a function, but if I name it WORK_DAYS_PER_WEEK, it can be said that I can find it very quickly, which is also in line with us. 2.1 is worthy of the name .

2.4 Avoid using encoding

The encoding here refers to the encoding of the naming, which can also be said to be a norm, but Martin strongly opposes the use of encoding, because encoding undoubtedly requires the programmer to master another language, which is completely a burden, and it is not good for pronunciation. . Here Martin points out several encodings by name:
1. Hungarian notation
2. Member prefix
3. Interface and implementation

The rules of Hungarian notation are: property + type + object name. I heard that it was created by a big Hungarian brother. The idea is not bad, at least the naming is kept uniform, but I checked the encyclopedia and found that there are too many abbreviations to memorize, and I don't want to memorize them. .
Member prefixes refer to things int xxx_m,m_xxxlike that. If you use underscore nomenclature , it's another matter. If it's a single-letter name, it's almost meaningless. It's just a sign of the old code.
Interface and implementation means that this is an interface, but you should name it without an I to mark it as an interface. In this regard, I do not particularly agree with the author's point of view, it does need to be considered.

2.5 Pick a good name

There are many requirements for a good name, the requirements are as follows:
1. Avoid mind mapping
2. Don't be cute3
. Class names should be nouns or noun phrases
4. Method names should be verbs or verb phrases 5.
Each concept corresponds to a word6
. No pun
intended 7. Use the name of the solution realm

Next, I mentioned many techniques and taboos of naming.
The first point is that programmers should not convert their special knowledge into variable names. For example, if you know the Fourier transform, it should be named Fourier instead of F. The second point, don't pretend to be cute and say something similar, the author gave the example of HolyHandGrenade and DeleteItems . Well, I know Holy Grenade is destructive because I played Worms. .
The third and fourth points are actually quite a bit of literary grammatical sense. Class should really be a noun, and method should really be a verb, no problem.
The fifth point, each concept corresponds to a word, just like fetch, retrieve, and get all mean fetch, and controller, manager, and driver seem to have the meaning of driving management. Please choose one to use, it's not a good habit to be around every now and then O_O.
Sixth, don't use puns. In fact, the author also wants us to make it clear that add is an insert or an append. Although this point is not so thought-provoking, it is good to follow it.
Seventh, use the name of the solution realm. Instead of using the proper nouns in the field involved in the code, it is more reliable to use the professional terms related to the computer directly. After all, the programmers who read your code must be programmers.

2.6 Meaningful Context

What Martin means here in context is that we are on a smaller scale where it is necessary to use context. For example, if I have a place name, then the state is very clear in the place name, it represents the continent, but it is not clear what it is used for outside, so we can name it addressState.
The meaningless context is that your context is too broad, and it is optional. Just like the code of my ofo bicycle mobile APP, there is ofo before each variable, which is meaningless.

Epilogue

In fact, it is the conclusion of the first and second chapters. The first chapter is just to instill an idea, and the second chapter explains some personal experience of Martin's name. Of course, I think "it is better to believe in the book than to have no book". Many opinions are great, but we should also learn from it. Come. I just like to follow my own way, it's not impossible, but if you think Martin's approach is better than yours, I think it can be used for reference.
Here I also set up a Flag. I will try to read the metaphysics part of the whole book this year, and refactor my roll call software along the way. Read about two chapters to write a summary, so that everyone can understand the book. .