One of the notes for programming craftsmanship

Chapter 1 Good defense

• The difference between making the program correct and making it usable: 1. it is easy to write code that can be used in most cases. It generates a regular output set for a regular input set; 2. correct code will never crash. For all input sets, its output will be correct. 3. not all correct code is good code, because the logic of some correct code may be hard to understand and difficult to maintain.
• When writing code, you may have many ideas, such as how the program runs, how to call it, and how to input it. We often have the following three common ideas: 1. this function will never be called in that way, and the parameters passed to me will always be valid; 2. this code will always run normally and will never produce errors. 3. if I mark this variable as "only for internal use", no one attempts to access this variable.
• Do not make any assumptions. unrecorded ideas will constantly create defects, especially as the Code grows. Anything that may go wrong.
• Defensive Programming is a meticulous and restrained programming method. To develop reliable software, we need to design every component of the system to "Protect" ourselves as much as possible. By explicitly checking the ideas in the code, breaks down the unrecorded ideas. This is an effort to prevent code from being called in an incorrect way.
• Defensive Programming is not a check error, a test, or debugging.
• Objection to Defensive Programming: 1. reduces the efficiency of code development. 2. obfuscated the responsibility of the Code. In addition to the necessary business logic, the Code should also judge various ideas.
• Support for defensive programming: 1. saves a lot of debugging time; 2. compiling code that can run correctly, but is slow, is better than writing code that runs normally most of the time but sometimes crashes. 3. most of the defensive measures we are considering here do not have any obvious performance overhead; 4. defensive Programming avoids a lot of security issues.

  We can use some programming skills for defensive programming.

• Use a good coding style and reasonable design. This prevents most encoding errors. It is best to make the text of a computer program clear.
• Do not rush to write code. You must think twice before proceeding. On the one hand, you must analyze the various possible situations of the Code to be written. On the other hand, you must complete all the tasks related to a code snippet before entering the next step.
• Don't trust anyone. Do not imagine that everything is running well, or that all the code can run correctly. Check all input and output with a skeptical eye and know that you can prove that they are correct.
• The goal of encoding is to be clear, not concise. Keep the code simple. Codes that cannot be maintained or are difficult to maintain are not safe.
• Don't let anyone do the repairs they shouldn't do. Internal affairs should be left inside. Applying defensive strategies at the beginning of encoding is much easier to use than improving code.
• Enable all warnings during compilation. Compiler warnings can capture many silly coding errors. In any case, you should enable the warning function of your editor. There is always a reason for the warning.
• Use static analysis tools.
• Use a secure data structure.
• Check all returned values. Do not let errors intrude into your program silently; endure errors that may lead to unpredictable behavior. At any time, you must capture and process the corresponding field at the appropriate level.
• Carefully process memory and other valuable resources. Any resources obtained during execution must be completely released. Do not close the file or release the memory because the operating system will clear the program when your program exits.
• Initialize all variables at the declared position. That is, the declaration and initialization of variables should be put together, so that they can be placed to operate on uninitialized variables.
• Postpone some declaration variables as much as possible. The declaration position of a variable is as close as possible to the position where it is used to prevent it from interfering with other parts of the Code. Do not reuse a temporary variable in multiple places. Variable reuse will complicate code re-improvement in the future.
• Use standard language tools.
• Use a good diagnostic information logging tool.
• Exercise caution in forcible conversion. Forced conversion may not only cause a conversion, but also change the accuracy of the variable.
• We can use constraints to verify our ideas. Constraints include: 1. preconditions; 2. preconditions; 3. invariant conditions; 4. assertions.
• Excellent programmers: 1. check whether their code is robust. 2. make sure that each idea is explicitly embodied in the defensive code; 3. expect the code to perform correct operations on input of useless information; 4. think carefully about the code they have written during programming; 5. write code that can protect yourself from others' stupidity.
• Bad programmers: 1. unwilling to consider errors in their code; 2. Release code that may cause errors for integration, and hope that others will find the error; 3. keep the information about how to use their code in your hands and discard it at any time. 4. they seldom think about the code they are writing, making it hard to produce unpredictable and unreliable code.

Chapter 2 elaborate Layout

• The encoding style used to be, is, and will continue to be one of the topics of belief contention between programmers.
• The programming style greatly affects the readability of the code, and no one wants to use the code that does not understand it.
• Our Code generally has three types of readers: 1. we not only need to be able to understand the code we just wrote, but also need to be able to understand what it means after many years; 2. compiler, focus on syntax, not on style; 3. others, such people are the most important and easy to ignore.
• What is a good style? 1. consistency; 2. Traditional, adopt a popular style in the industry; 3. concise.
• Style of brackets: 1. K & R style; 2. Hanging style; 3. indent style; 4. Other style.
• There are more than one good style. The quality and applicability of each style depend on the environment and cultural background. Select a good encoding style and stick to it.
• Multiple styles help us write better code.
• An organization requires an internal encoding style. This improves the quality of code and makes software development more secure. Sharing the benefits of the same style is far beyond the price paid for consent. Even if you disagree with this standard, you should abide by it.
• When there is a clear encoding style in an organization, we need to develop one. This is a task that requires careful consideration. It should be carried out properly and resolutely.
• A good personal style is not necessarily the best for programmers in the entire team. The standards you want to create should not be suitable for your own aesthetic habits. They should integrate the code of the team and avoid common problems.

  The following policies can be taken to create an encoding style:

• Who is the standard? Define the scope of use.
• Won wide participation. Only when you participate will you be more willing to follow the rules.
• Make achievements. Finally, there should be an understandable document.
• Standardize best practices.
• Highlight important points.
• Avoid hot spots. Leave rare and troublesome situations to personal decisions on the premise that there will not be too many disagreements.
• Gradually improved.
• Make plans for promotion.
• When creating the encoding style, you need to know the size. The finer the specification, the better.
• We have reason to think that the Code with beautiful layout is well-designed code, and the code with messy format must not work hard.
• Excellent programmers: 1. avoid meaningless debates and be very sensitive to others' opinions; 2. modest self-denial, do not think you are always right; 3. understand how the layout affects readability and try to write clear code; 4. adopt an internal style, even if the internal style conflicts with their personal preferences.
• Bad programmers: 1. close your eyes and stick to your own opinions. I think "My opinion is correct". 2. argue with everyone about the most trivial things and consider these as opportunities to prove their advantages. 3. no consistent personal encoding style; 4. the style of others' code is illustrated.