Talking code-writing self-expressing code

Talking code-writing self-expressing code

Wang hongliang

ISBN 978-7-121-20876-8

Published in August 2013

Pricing: 45.00 RMB

Page 1

16

Contents

A variety of problems may occur in poorly written code, which may lead to poor reading experience. If the code is not well written, the document and code are inconsistent, and the comments and code are inconsistent, it is difficult for maintenance personnel to understand the code and to enter the project team. If the code is not well written, you need to extend the function. It takes a long time to modify the bug.

Self-expressing code is an idea of writing code in a way similar to natural language.

Code readability, scalability, and testability are important reference indicators for associating code quality. This book analyzes the causes of poor code from various perspectives, and starts from the code naming, commenting, style, structure, architecture, and other aspects, specific improvement suggestions are provided for improving the design capability, familiarizing yourself with the development environment, understanding the programming language, and improving the English proficiency.

Directory

Chapter 1 poor experience brought by poor code 1

1.1 code readability Question 1

1.1.1 naming Question 2

1.1.2 annotation 6

1.1.3 style issues 8

1.1.4 structural issues 11

1.1.5 architecture issues 18

1.2 code testability 22

1.3 code maintainability 22

1.3.1 demand changes are hard to cope with 23

1.3.2 ambiguous bug 23

Chapter 25 how to generate inferior Code 25

2.1 lack of theoretical knowledge 25

2.2 unfamiliar with programming languages 29

2.3 unfamiliar with the development environment 31

2.4 do not understand the design method 32

2.5 poor programming habits 32

2.6 insufficient English skills 35

2.7 misleading Management Personnel 36

Chapter 3 self-expression code 39

Chapter 41 supplement to theoretical knowledge

4.1 basic object-oriented knowledge 41

4.1.1 encapsulation 41

4.1.2 inherit 42

4.1.3 polymorphism 44

4.2 basic design principles 45

4.2.1 single Responsibility Principle 45

4.2.2 principle of open and closed 46

4.2.3 Lee's replacement principle 48

4.2.4 interface separation principle 48

4.2.5 Dependency inversion principle 49

4.2.6 dimit law 50

4.2.7 do not repeat yourself 51

4.3 lap complexity 52

Chapter 5 familiarity with the programming environment 53

5.1 save action and automatic formatting 53

5.2 quick fix 58

5.2.1 category 59 missing

5.2.2 Method 60 missing

5.2.3 missing variable 61

5.2.4 Type Mismatch 62

5.3 reconstruction 63

5.3.1 renamed 64

5.3.2 change method signature 68

5.3.3 extraction method 69

5.3.4 move 73

5.3.5 introduce the parameter object 76

5.3.6 introduce interface 77

5.3.7 upward extraction 78

5.3.8 extract constant 81

5.3.9 local variables become domain variables 82

5.3.10 import factory 82

5.4 Automatic completion 83

5.5 outline 84

5.6 eclipse shortcut 86

Chapter 14 Programming Language Learning 88

6.1 annotation 88

6.2 exception 94

6.3 reflection 97

6.4 generic 100

Chapter 1 Study of Design Methods 7th

7.1 Design Model 101

7.2 dependency injection 102

7.3 clever use of map 103

7.4 use a bit mask to reduce the number of classes by 107

7.5 list processing Z-Order 110

Chapter 5 improvement in English proficiency by 8th

8.1 part of speech 113

8.2 tense 115

8.3 syntax 116

8.4 negative words 117

8.5 paired words 119

8.6 synonym 120

8.7 prefix and suffix 120

8.8 abbreviation 122

8.9 correct words 122

Chapter 1 improvement of programming habits 9th

9.1 improvements in naming 124

9.1.1 basic naming principles 124

9.1.2 package name 125

9.1.3 Interface Name 125

9.1.4 class name 125

9.1.5 annotation 126

9.1.6 enumeration name 126

9.1.7 method 127

9.1.8, variable 129

9.1.9 constant naming 130

9.1.10 similar naming 130

9.2 improvement in comments 131

9.2.1 Java SDK 131

9.2.2 todo, fixme, and XXX 132

9.2.3 other notes 133

9.2.4 method comment 133

9.2.5 class comment 133

9.2.6 copyright 134

9.3 style improvement 135

9.3.1 indent and alignment 135

9.3.2 space and empty row 138

9.3.3 President and line feed 140

9.4 Structure Improvement 140

9.4.1 shorten the length determination by 140

9.4.2 shorten the Long Branch by 144

9.4.3 reduce the number of parameters by 148

9.4.4 reduce nested layers by 150

9.4.5 remove duplicate code 152

9.4.6 separation of ambiguous relationships 155

9.4.7 multi-dimensional change 156

9.4.8 shorten the length by 158

9.4.9 regular expression 158

9.4.10 self-similar object 160

9.4.11 homogeneous processing 161

9.5 architecture improvement 162

9.5.1 MVC 162

9.5.2 inclusion relation 164

9.5.3 inheritance 164

9.5.4 package division 165

9.5.5 internal class, internal interface and internal enumeration 166

9.5.6 anonymous 167

9.5.7 limited value range: 168

Chapter 5 test code self-expression improvement 10th

10.1 testing code readability 175

10.2 maintainability of the test code 179

10.3 scalability of the test code: 179

10.4 test syntax 180

Chapter 2 lambda expressions 11th

11.1 filter 183

11.2 foreach 183

11.3 findany and findfirst 184

11.4 sorted 184

11.5 uniqueelements 185

Annex 186

Media comment

Recommendation Sequence

 

Classical Books that teach people to write programs, such as Java programming ideas. Similar to the positioning of teaching materials, they teach new programmers to write code in a simple way. Rich and experienced books, such as objective Java and design patterns, organize and explain many programming experiences in depth. Many tips and experiences on how to write clean code are also described in "clean code.

However, this book "talking code" tries to help programmers who are on the front line to write code that is easier to understand from different perspectives. Writing code is like building a building. We hope that all the project code will be like a virgin land that has not yet been opened up, but the real situation is often faced with the ruins of the relocated house. These confusing codes are either left by others or left by ourselves for a long time, and we often do not have many choices.

The talking code re-describes these phenomena from the first line, and proposes a solution with great care. For example, if you want to scroll the scroll wheel or pull the scroll bar continuously, is your method or class too long? When you need to constantly check the method implementation, is the method name unable to express the meaning of the implementation? Is nesting too deep when you need to draw a flowchart to understand the logic of a method?

This book describes naming, commenting, structure, architecture, and programming style in detail. Some of these suggestions even detail whether the "is" or "can" is required, whether the interface needs to be added with I or the suffix of "-able. This article also describes how the design pattern and object-oriented design principles help programmers write self-describing code. To understand it thoroughly, you also need to read relevant books. For Java 8 that has not yet been officially released, the author also introduced Lambda in Chapter 11th.

In addition, I have known Wang hongliang for a long time. More than a decade ago, when new programmers were still suffering from Tan haoqiang's "C program design, wang hongliang, who is still at Northwestern University of Technology, has used C ++ to write an eye-catching RPG Game in his dormitory. Now, he still hasn't abandoned the first-line development. As a programmer, I admire it.

I hope this book will help programmers write more intuitive and concise code.

 

Thoughtworks agile consulting Consultant

Chen Jinzhou (@ mechiland)

February 21, 2013

Preface

Origin of Self-expressing code

 

We have read a lot of code with poor reading experience, including the mouse wheel test program (referring to long files, long methods) and the brain Wheel Test Program (referring to complicated logic judgment and chaotic relationships) memory testing programs (a large number of variables or constants), eye testing programs (similar names, but different meanings), logical thinking testing programs (Cyclic reference inclusion relationships), and so on. These poor code brings us a variety of poor reading experiences.

We once suffered from an accidental bug that could no longer be reproduced, but we found that the necessary steps were more than thirty steps, but we could not find the root cause of the problem after the reproduction, there is no way to solve the problem. After dozens of log statements are inserted, the cause of the bug can be located, but the bug cannot be modified. Very careful analysis, slowly modify, get rid of this bug, but found that it has caused a new bug.

Demand changes may be one of the biggest headaches for programmers. They lead to a new process that needs to be analyzed, modified, and tested. What is more difficult is that, if this requirement is met, another completed function must be destroyed, but the user wants to have both the fish and the bear's paw.

When new users enter an existing development project, they often face problems such as inconsistent code and design documents, inconsistent code and comments, chaotic code structures, and inconsistent code styles, I had to spend a lot of time learning. It is a painful thing to face a code library with a large amount of effective information, which leads to an impulse to overwrite the code. However, during development, the project manager is always urging: The time is very tight, documents are abandoned, and comments are abandoned.

What are the problems that lead to these painful experiences? Why are these painful experiences? How can we avoid these painful experiences? Chapter 1 of this book uses this as the starting point to analyze the causes of poor code from three aspects: code readability, testability, and scalability, summarize the terms of naming, commenting, style, structure, and architecture, and propose corresponding improvement plans in sequence.

The term "self-expressive code" is original to the author. Before that, the "self-documenting code" and "self-describingcode" appeared ). The author believes that "self-expression code" is more expressive than the latter two. According to the theory that "code is the only document of Software", code should be self-expressed, so that readers can see the code and know what the software is doing, this is the origin of the word self-expressing code. As the name suggests, the writing method that allows the code to express itself is self-expressing code. The method for writing self-expressing code should be the same as writing an article in a book. If the code is written in the same way as an article, you do not have to rely on complicated comments and thick documents to understand the code. The Code itself can demonstrate its role. Maintenance personnel do not have to worry about inconsistency between codes and documents or comments.

The worst code is written as follows:

Scene. Fight (hero, enemy, Kongfu. Fist); I don't know who beat anyone.

Code written in common mode, such:

Hero. Fight (enemy, Kongfu. Fist); knows the meaning of the code, but the reading experience is not good enough.

The code written in self-expression mode is as follows:

Hero. Fight (enemy). With ("fist"); if you don't read those symbols, read them as a sentence.

Chapter 1 describes how to write code in a way similar to natural language, and introduces the concept of "self-expressing code.

If is the condition, then the loop is for. In this way, the code of "directly expressing your mind" is piled up and interacted with each other, greatly increasing the complexity of the Code. However, the reason for this problem is that due to lack of theoretical knowledge, the code writer does not know how to characterize the complexity of the code, and how to reduce the coupling degree. In Chapter 2 of this book, I will explain some common object-oriented theoretical knowledge to help programmers first master these theoretical knowledge.

When many experienced programmers position the cursor in a continuous direction key manner, I am deeply unfamiliar with the integrated development environment, which is also one of the reasons for poor code quality. There is no shortage of programmers who are familiar with the refactor menu that has been promoted to the main menu. However, using outline to quickly locate code and using the debugger tool, task list management technology, and other methods is also a blind spot for these people. Therefore, chapter 1 of this book takes eclipse as an example to explain some commonly used functions of integrated development environment that help programming a lot.

Java 8 is coming soon. However, many programmers are still restricted to using Java only. As for the new features of several intermediate versions, programmers cannot understand them at all. When programmers see more concise code written with new features, they will not understand, do not understand, and can not write themselves, so they missed a lot of opportunities to improve the code. In chapter 1 of this book, I will explain some new features launched after Java 6th and explain some of the usage skills to help readers better understand these new features.

In the past, code books were from the United States, and the use of English is not a problem for Americans. In these books, the topic of English is rarely mentioned. However, in some Asian countries, English may be a major obstacle for programmers. There are many problems in code writing due to insufficient words, unclear syntax, and insufficient part-of-speech. This also brings a lot of reading troubles. In fact, the English required for writing code is not very advanced, and it does not require IELTS scores to reach a certain score line. As long as you master some basic English skills, you can make the code easier to read and understand. Chapter 1 of this book analyzes English from the perspectives of correct words, parts of speech, syntax, and tense to help programmers better name English. In addition, this book also provides a list of available prefix, suffix, Pair Words, synonyms, and so on, to become a useful supplement to writing self-expression code skills.

Writing code is not physical labor, but mental labor. Taking writing code as a physical labor makes it difficult to ensure the level improvement of programmers and the reliability of software quality. Let alone the readability, testability, and scalability of code. Writing code is not only a technical work, but also an artistic work. In the code writing process, you need to constantly adjust and modify the code. It is enough not to write the code concisely. The Code should be able to be quickly read by the reader, and can be easily tested and easily expanded. Chapter 2 explains how to cultivate good programming habits.

The metaphysical rules and regulations cannot facilitate the writing of high-quality code. The coding norms should keep pace with the times, and managers should discard old practices and rules at any time. The application of any good method is inseparable from the support of managers. This book analyzes and summarizes the management reasons for poor code generation. But how to improve the management level is a huge topic. Because it is not the main topic of this book, this book is divided into love.

As a feature of the next generation language, lambda expressions have been added to several advanced programming languages. However, Java has not added lambda expressions, and Java 8 has declared that it is necessary to add Lamda expressions. Chapter 1 of this book provides a preview version of Java 8 to understand the features of lambda expressions in Java.

May this book help readers.

Wang hongliang

April 2013

In Beijing