"Code Neat Way" Reading notes

?? At first I liked this book probably for non-technical reasons, there are many illustrations I like in this book. The first sentence of the first chapter of the book says this: there are usually two reasons to read this book: 1. You are a programmer. 2. You want to be a better programmer. We need a better programmer.
?? Each chapter of the book can be summed up a sentence, in fact, the beginning of each chapter of the illustration is the concentration of this sentence.

?? The first chapter of this book is a discussion of what is neat code, citing Bjarne Stroustrup (the father of C + +), Grady Booch (one of the founders of UML) and, of course, Uncle Bob (author Robert Martin of this book) 's own understanding of the neat code. By the way, the code on the chart above should be a bowling scoring program (I don't know if you see it clearly, haha).

?? Whether it is a real world or a software project, naming is a headache, to give a child a name to know, you want to include your child's expectations in the name, you want the name to read it well, at least not the future to become the laughingstock of others (such as Pang, Wei, such as the name), You might also want to consider the arrangement of genealogy classes and so on. Naming in software projects will be more complex, the simple naming principle is "see the name", of course, you also need to prevent naming conflicts in various ways, different programming languages have their own unwritten like contract naming rules and methods (such as the Hungarian nomenclature), which may be a matter to consider. I personally do not like the Hungarian nomenclature, plus the feeling of a type prefix is always bound together with this thing, just like the malloc function in C language to allocate memory to create an array of 100,000 elements, you would like to use the following one of the writing? Remember: A good name is equivalent to writing a useful comment for the code.

 int  * myArray = NULL; /* notation 1 */ MyArray = malloc  (100000  * sizeof  (int )); /* notation 2 */ MyArray = malloc  (100000  * sizeof  *myarray);  

?? The third chapter is about the function, said the sentence: "Function should do one thing." They should do it well. They should do it only. "(a function should do only one thing, do one thing well, and do it only), sounds simple but it's not easy to practice this principle, so there's a lot of bad taste in our code (see chapter III of Refactoring: improving the design of existing code). In fact, the rise of a level, we are in the design of the class should also be the case, this is the principle of object-oriented design of the single principle of responsibility (SRP), when our code has a lengthy method or a huge class, we should be based on responsibility to split it, so that the structure of the program will be reasonable, Finally achieve the goal of "high cohesion". Of course, there are many ideas in this chapter, including: Command Query separation (a method that either executes a command or returns query data), DRY (do not repeat itself), Prefer Exceptions to returning Error Codes (exception is better than return error code) and so on.

?? The fourth chapter is about the comment, there is a sentence I like, said: "Comments does not make the" to bad Code. " (Comments are not a remedy for poor-quality code.) In fact, good code can be readable even without annotations, but proper annotations make the code more readable and maintainable.

?? The fifth chapter is about code style. Modern Ides (integrated development environment) almost all have the function of code formatting code, you just need to set up the code style you use, in fact, not only the IDE, many advanced text editing tools can also be formatted according to the specified style of your code. What style of code is not key, the key is that members of the entire project team should use the same code style, so that many people write code that looks like a person writing. The style of parentheses I use in the code is 1TBS (one True bracing style, also called K&r style, this style is Kernighan and Ritchie two teachers in "the C programming Language" The code style used in the book), of course Allman style (the code style used by one of the authors of the FreeBSD system) is also a good choice.

?? The sixth chapter discusses objects and data structures, after reading the feeling is that although we yell every day to the object-oriented programming, but many times we have used the degenerate structure of the class, including our development often used in the blood loss model and anemia model (transaction script mode) and the object-oriented design concept is inconsistent. I have to admit that I may not have grasped the author's point of view while reading this chapter.

?? The seventh chapter on error handling (exception) is very wonderful, neat code in the processing of errors should be the separation of concerns (do not mix with normal business logic), and the object-oriented anomaly mechanism is a way to deal with the operation of the program at run time without disrupting the original operation of the abnormal situation. This chapter has two points I particularly appreciate, one is "use unchecked Exceptions" (non-inspected exception allows you to handle the exception in the appropriate place, and the appropriate place is where the exception affects the code execution logic, regardless of what kind of application, should be as far as possible to the user to hide the occurrence of the exception, Unless there is an irreparable condition, this is the design that conforms to the least surprising principle), and the second is "Don't return null" (if a method returns NULL when it is out of the state, then the caller will have to check the return value frequently to determine if there is an error, and once you forget it, it is possible to make a mistake. Since NULL is an exception condition, it is obviously better to throw an exception in lieu of returning null.

?? The content of the eighth chapter is of great significance for practical development, as it is unavoidable to use third-party tools in our projects, so we need to include these things neatly into our systems, and we need to consider the problem of system boundaries. Sometimes we will be hard to find some bugs in the system come from third-party tools, of course, we basically do not have the time to learn and study third-party tools or write their own code to implement the functions of third-party tools, but we should at least first Test third-party tools. In my previous projects, using the well-known third-party tools provided by Apache, my practice was to write test code to confirm the usability and effectiveness of these tools, although sometimes it might be too cautious, but this habit and practice itself is good. In this scenario, the adapter pattern is a good design that not only overwrites incompatible interfaces with compatible interfaces, but also prevents the system from changing the boundaries by re-encapsulating the third-party tools.

?? The Nineth chapter is the unit test. Uncle Bob is The advocate for TDD (test-driven development), and this chapter is about how to write neat tests, and Uncle Bob's answers are first rules (Fast, independent, repeatable, self-validating, timely).

?? The tenth chapter introduces the design of the class, the most important is the SRP (single duty principle).

?? The 11th chapter is about the design of the system, the opening quote from Microsoft Chief Technology Officer Ray Ozzie, a sentence: "Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test. " (Complex to human lives, it kills the developer's life, making the product difficult to plan, build and test). This chapter is excellent for developers wishing to learn about aspect-oriented programming, including the discussion of dependency injection, proxy mode, and AOP.

?? The 12th chapter discusses the iterative evolution of the system.

?? The 13th chapter discusses concurrent programming very often, many developers are afraid of concurrent programming, some developers superstition multithreading can solve all the concurrency problems, if you are one of these two types of people, this chapter will teach you real concurrent programming. In this chapter I have re-organized an article that has been published on CSDN's blog, entitled "Summarizing and thinking about Java concurrency programming."

?? The 14th chapter is a wonderful example of the continuous improvement of the code, you can read it yourself. The 15th chapter to the 17th chapter is the reconstruction, quite wonderful. If you haven't had time to read the refactoring: improving the design of existing code, you can read the bad taste of the code discussed in these several pieces and improve the program first.

?? In short, the book from the introduction to the appendix are extremely exciting, the code in the book is written in the Java language, hurry to read it.

"Code Neat Way" Reading notes