Reading notes for Code Simplicity

Preface:

This book is a programming must read, for how to optimize your code is very helpful. After reading this book for nearly a week, I spent more time on practicing the code. I thought about and optimized my own code according to the suggestions in the book, and found that the process was actually very happy. This time, the reading notes introduce what I learned from this book.

Article purpose:

  1. Trying to write concise code is the basic quality of a programmer, always pay attention to the details

  2. Do simple things to the best of your ability to do more challenging things

  3. Collect the basic knowledge and content points of the Simple Code book and review what I think is important in the book.

  4. Summarize the general content of the entire book with mind mapping (the mapping content is relatively large)

Description:

Why did the author through the most simple code to write clean code of some Suggestions, from the simplest method of naming conventions gradually extended to class, system, to the final use of a practical case about a code refactoring experience, the authors experience in the difficulty level and pace of the control is in place, you don’t need to worry about a is the theory of complex, very organized.

The content of this book is more important for practical use, providing a large number of code and instructions for iterative transformation (although it is sleepy to read), if it is a theoretical book to read this book is meaningless to scan it. At the same time, this book focuses on the word “concise”, and uses a lot of cases and practical experience to prove various mistakes that programmers are prone to make when writing code. A little look at it and you can see that many suggestions are “very similar” to how you usually write code.

​

Recommendation level:

Highly recommended, one of the must-reads for programmers, the author offers a lot of advice on how to write clean code, as well as how to handle code in the actual code.

If you want to see the code improvement in action, see Appendix B for how the SerialDate class is iterated and modified. It is very helpful to learn about the code improvement.

Perhaps the biggest problem is that there is no source code for this book. Many of the code optimization ideas in the book are difficult to understand when reading

Mind mapping:

Since the notes of this book are difficult to be sorted out by a single article, in order to save the time of reading the article, I refined the contents of the book and simplified the notes and key points into a mind map. Readers can refer to the mind map to read as needed:

Share.mubu.com/doc/2oVODZ8…

Curtain mind map

Book Content analysis:

Key Reading:

Some important points are listed below. The sections related to code folding in the next few chapters are omitted. These are important to note, but they are not taken into consideration because I cannot find ready-made code (although the code can be read on paper, it is painful and difficult to understand, and I think it is inefficient). So list only the previous suggestions and the final summary.

PS: The following is an excerpt from a mind map

  • Chapter 3: Functions

    • Focus on

      • Keep the number of parameters controlled at all times

      • The function returns the expected content and runs the expected behavior

      • Ways to avoid side effects

      • Having a good name is the key to a good method

    • Introduction to the

      • How to write an easier and more awesome way

      • The first step of functional encapsulation, practice writing good functions all the time, okay

  • Chapter 4: Notes

    • Focus on

      • Writing good code is the key, write clean code first, then think about writing comments

      • At best, the code itself interprets the comments

      • Try to write good notes that are easy to understand

      • Good notes not only make the reader understand, but also make the reader learn something new

    • Introduction to the

      • Writing a comment is easy, but writing a good comment is not.

      • Programmers are too lazy to write comments because of “excuses”

      • If your code is expressive enough, you don’t need comments, otherwise add your comments

  • Chapter 7: Exception handling

    • Focus on

      • Some tips for exception handling

        • Separate methods for try/catch

        • From large exceptions to fine exceptions

      • Do not return Null values

      • Exceptions need to be treated as a single responsibility, not tied to methods

    • Introduction to the

  • Chapter 9: Unit testing

    • Focus on

      • Test unit: One test for one assertion, and the test unit should be as short as possible

      • The FIRST principle

        • F: fast

          • Testing can be done quickly

        • I: independent

          • The tests are independent of each other

        • R: Repeatable

          • The test will pass in any environment

        • S: Self-sufficient verification

          • There is a Boolean output and you can verify your results

        • T: in a timely manner

          • Tests should be written in a timely manner

    • Introduction to the

      • Learn to use TDD’s form of test-driven development

      • Unit testing is very important and necessary

        • Benefits of testing

        • Clean test

      • The three laws of TDD

        • Don’t write production code until you write test code that doesn’t pass

        • Only write unit tests that just don’t pass

        • Write just enough production code to pass the tests

  • Chapter 10: Classes

    • Focus on

      • A small number of large classes is not necessarily better to manage than a large number of small classes

      • Do this with as few classes and methods as possible

      • Classes should not have too many responsibilities and distractions

    • Introduction to the

      • The key is the split of the class

        • Find ways to break down when cohesiveness is lost

        • Abstract life: do you want a treasure chest for everything or a toolbox full of different things

  • Chapter 17: Taste and Inspiration # key

    • Focus on

      • Summarize the main points of the book

      • Review the key points of the book

    • Introduction to the

      • A very important chapter, which summarizes some of the most important things in the book in one chapter

      • The last chapter determines which parts of the book to read

The author’s core ideas:

I read it carefully from beginning to end and took a lot of notes. Here are some of the author’s core ideas:

  • Single responsibility: Whether you’re writing simple or complex code, you need to focus on the separation of responsibilities.
  • Simplicity: Make every effort to optimize your code and develop good programming habits.
  • Iteration: The author uses a large number of cases and code to express how the code is iteratively improved step by step, to constantly think and improve
  • Notes: Good notes are really, really important, although the notes in this chapter are really more like the author’s teasing and complaining
  • Critical spirit: dare to refactor code regardless of level, and reflect and think
  • Refactoring: The magic of how every seemingly insignificant detail changes the way a system is built

prologue

The prologue shows what the author is trying to do with the book. The author encourages the reader to challenge the code and makes the following points:

  • God is in the details
  • 5 s philosophy
    • Collation: Naming conventions
    • Clean up: Every piece of code is where it’s supposed to be
    • Clear: The annotation and processing applied diamante
    • Clean: Clear organizational structure
    • Physical beauty: Willing to improve

The first chapter should have the code

In the first chapter, the author is not begin to introduce how to write good code or some skills, but to explore advocated AI programming (actually have long the concept) as well as the importance of writing code, the following records in the book for writing code to some attitude and personal understanding is the author of the code is the pursuit of perfection, so the beginning then encourage readers to write clean code:

  • Code lives forever. There has to be code
  • The lebron rule: Later equals never
  • Don’t blame bad code on external causes
  • The premise of good code
    • Be decisive and down-to-earth, without hesitation or useless details
    • Pleasing in appearance, grace, and grace in manner

Taste and inspiration

Personally, if you are pressed for time or want to get a brief overview of the book, go to the last chapter, “Taste and Inspiration”, which introduces some of the core ideas of the book as if the author gave you a summary, very conscientious. It is recommended that you focus on the contents of this chapter, which contains a lot of small points on how to write simple code in ordinary times.

Appendix: The appendix is easy to ignore, although it is an introduction to the concurrency module and test and detect exceptions. In this section, the author tells an interesting story about his own experience with tuning concurrent code.

Excerpts from appendix

Here are the notes in the appendix about how to count the number of paths for a thread

How to calculate the number of paths:

Assuming N instructions and T threads, this will result in T*N steps

Assuming step AB and thread 12, we will have the following:

1122, 1212, 1221, 2112, 2211, 2121

They are characterized by the fact that each T will occur N times, because the execution will be completed regardless of the order in which it is executed. Right

This leads to a formula:

(N*T)! / N! ^ T (! Is the factorial operation)

Example: For code with 2 steps and 2 threads, insert the formula: (2*2)! / (2! ^2 = 24/4 = 6

There are six things that will happen

Which raises the question, what has synchronized changed?

Let’s assume that we have two threads and we’re going to get N! The factorial of the instruction becomes a constant 2

Personal Insights:

For personal book value, dry with a book, not pure flapping, but against the code of the agent case, especially note this chapter, used to like to write a lot of comments for colleagues don’t understand to come over to ask (involving business problems would be happy to discuss with colleagues, of course), but read books to do some extra feeling before. People after work, gradually formed the habit of writing documentation, regardless of demand size, always like to write a written transcript the demand as well as the outline of his thoughts, practice and found that very useful, although later would think written document is repetitive or sometimes forget = – = written document, and some may not very accurate, But it does help to review your business and requirements for yourself. Anyway, I’m glad I stuck with this book.

Here are some personal insights, and if you don’t want to read, here are some personal comparison points:

  • Look and think, and look and practice. Practice counts

  • Code is not a step in place, the code will never have an optimal solution, according to their own ability to constantly explore a better solution. Deliberate practice

  • Some tips for not wanting to read

    • Single responsibility

      • Is the code really only doing one thing? Is it fooling itself

      • The catch-all rule to see if you can only do one thing: Add demand

      • Is the approach “all in all”

    • Don’t repeat yourself

      • “CV” programming will stay at “CV”

      • Modern editors can take a lot of thinking away

    • What is simplicity

      • Without comments, reading code is like reading business logic

      • There are no outdated comments, no wrong comments, and no useless comments

      • Do the most with the least code. Code reuse is high

      • No duplication, single responsibility

    • Telescope,

      • Learn to split responsibilities and divest responsibilities
      • Think about what object orientation is
      • Keep improving, write more concise code

    • Criticism: Keep accepting criticism to make progress

Here are a few examples that come to mind from everyday life, as well as a few thoughts that readers can write about and criticize when they encounter or encounter programming habits:

  • Before making the requirements, write a rough draft of the requirements document. Don’t be very precise, but give a brief explanation of the reason for the change

    • Introduction of demand
    • Train of thought
    • Solution Step 1, 2, and 3

  • Like a line of code line of comment, in the premise of ensuring the completion of the task to complete the personal comment code

    • Writing code is not writing articles. You don’t need to cover everything
    • Too many comments tend to obscure the value of the code itself

  • Methods with many parameters are easy to write and often easy to ignore

    • This demand likes to like +1, this week is not good

  • Unconsciously write a lot of useless notes, the same as in the book mumbling

  • Break the habit of writing lots of comments

  • Break the habit of liking CV code

  • Think about whether the code you’re writing conforms to the design rules, and whether you’re duplicating your work

  • Make method and parameter naming more canonical

  • Review your code, paying attention to its format and line count

  • Consider whether design pattern ideas can be applied at the code level.

  • Reduce parameter names and pay more attention to method names

  • Laziness is the root cause of bad code

Book Summary:

The book also suggests that the ideas in the book can be translated into actual code, because many of the problems the author raises are obvious from his own code (redundant comments, redundant methods, etc.).

First talk about the advantages of this book, although older may be, and some ideas may not be very accord with the development of modern thought, but still can see many places worthy of learning, pay more attention to details, such as thinking about a new direction and dare to break your own code, personal check missing from the book, reflect the need to correct some of the programming ideas, It does have a practical effect on improving one’s programming skills.

Say again shortcomings, first of all, is the part code, personally think that part of the case code to be, because a lot of code at the same time there is no context, although the author explains the readers but still confused (of course, can also be personal comprehension questions), anyhow is not part of the code case really fog. Secondly, the book contains a large amount of code, which requires a long time to digest and absorb, which relatively affects the immersive reading experience. Of course, this book is more to support the reader to practice.

Personally, this book is a pity that code section, because in the book the author from 12 after chapter introduces how idea into the code, join the use of actual cases how to rewrite the “bad” code, a rough look at the next while it is possible to understand the author want to do our best to inform the reader some optimization of ideas, but people on the Internet looking for a long time still didn’t find relevant source, a shame. At the same time many pages of code and code without context can be a little daunting in a book.

In the book, the author recommends checking out The 135 pages of “Literal Programming” for a good example of a split, and will take the time to look at it later

参 考 答 案 :

Only through criticism can we learn anything. That’s what doctors do, that’s what pilots do, that’s what lawyers do, and we programmers need to learn how to do it. (Page 252 of the book)

I’m just going to take a screenshot of =-=

Conclusion:

Welcome to mind maps for more content. In order to avoid writing too long, put more details into the mind map to help you think and review. I will read Refactoring later. Although it is an old book, I saw many people recommend it, so I bought a copy and read it. This book also spent a lot of thought to write reading notes, I hope readers give advice.