How to write good code - Defensive Programming Guide

introduction

In daily work , Do you have this feeling ：“ good ” Code and “ Bad ” Code , Can meet the needs of the product . But different people write code , In efficiency 、 quality 、 Maintainability 、 Extensibility 、 Readability and other aspects vary greatly . idea 、 conceived 、 No matter how well the architecture is designed , The written code tramples on the pit in three days , This is just a piece of paper . Therefore, the robustness of software is an important standard to measure the level of an engineer . How to improve the robustness of software ？ Reasonable top-level design 、 Complete testing is essential , But ultimately, it's about improving code quality .

Defensive programming is a way of thinking about safe coding . It is seen as a means to reduce or eliminate Murphy's law . In the work of programmers 《Code Complete》（ The code of ） in , Defensive programming is introduced in detail . At the same time, many large factories at home and abroad take defensive programming as one of the means of quality construction . This article will introduce defensive programming and how to apply it in practical scenarios .

Murphy's law

If there are two or more ways to do something , And one of the options will lead to disaster , Someone must have made that choice . This is a pessimistic thought , Think that all bad things that may go wrong will happen . So when you have this idea to do design , It is necessary to predict the worst situation and take corresponding measures . At the same time, users do not need to think complex , You can use a system by intuition , The so-called fool proof design . Such as 3.5 Inch floppy disk design , It is designed that only one situation can be inserted .

What is defensive programming ？

Defensive programming , The central idea is this

Subroutines should not be corrupted by incoming bad data , Even the wrong data generated by other subroutines . Simply speaking , Is to doubt everything , Think that the environment outside your own code is untrustworthy , under these circumstances , Consider how the code should be written .

Defensive programming and defensive driving

Defensive programming , This concept comes from defensive driving . In defensive driving, we should establish such a kind of thinking , That is, you can never be sure what another driver is going to do . In this way, you can ensure that you will not be hurt when others make dangerous actions . You should take the responsibility to protect yourself , Even if other drivers make mistakes .

Take a real scene , For once SQL For example, query ：

Class Main {
 private Connection con = = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASSWORD);
 
 public List<Student> doQuery(String name) {
 Statement stmt = conn.createStatement();
 ResultSet rs = stmt.executeQuery(&quot;SELECT id, grade, name, gender FROM students WHERE name=&quot; + name);
 List<Student> studentList = new ArrayList<>();
 while(rs.next()) {
 long id = rs.getLong(1);
 long grade = rs.getLong(2);
 String name = rs.getString(3);
 String gender = convertGender(rs.getInt(4));
 Student student = new Student(id, grade, name, gender);
 studentList.add(student);
 }
 return studentList;
 }
 
 
 private String convertGender(int gender) {
 switch(gender) {
 case 0 : return &quot;male&quot;;
 case 1 : return &quot;female&quot;;
 }
 return null;
 }
}

The above code is relatively simple , It also seems to achieve the requirements we want ： Query all students who match their names . But experienced developers , You can find many problems , such as ： Whether the database connection is established normally ？ Whether the return value of the database has been verified ？ These problems are summarized , We can draw the key principles of defensive programming .

Border defense ： Check all external inputs

In the concept of defensive programming , All external inputs are untrusted , Check whether it is within the allowable range . The items to be checked here include , Null pointer 、 An array 、 Illegal participation . Especially when we are writing a public method , I'm not sure this method will be used at some time in the future , Called by an external system , Doing a good job of input checking can not only protect the robustness of its own program , It can also let the external system call with confidence .

This one above case There is an obvious parameter transmission vulnerability in , Enter the reference name It may be used by external users SQL Injection attack , Such as the input name = "zhangsan or 1 = 1", You can get all students Information , Obviously, this is an entry that does not meet our requirements .

In addition, this external input includes not only the incoming parameters , It also includes any data obtained from outside the method , Including the data queried by the database, etc .

exception handling ： Choose between correctness and robustness

• Correctness means ： The program never returns inaccurate results , Even if doing so will not return results or exit the program directly .

• Robustness means ： The system can still operate normally under abnormal input or abnormal external environment , Even if the output result is wrong or incomplete .

Correctness and robustness are often contradictory , When we check the wrong data , You also need to decide how to deal with it . Defensive programming does not cover up errors , It won't hide bug. This requires a trade-off between robustness and correctness . In the scenario of extremely low tolerance , Such as rocket launching system or medical system , Correctness is better than robustness ; In consumption scenarios such as e-commerce , Give priority to robustness , After all, choosing goods is not successful , Just refresh it .

In the above case in , If the database connection fails , It is better to retry or return the error code , Instead of letting the program exit .

Should be inspected ： There is no completely reliable external environment

We are coding when , There will be many calls and interactions of external methods , Be alert to all external calls . these API Or the third-party class library is also written by people , What people write means that there may be bug. A good idea is to follow your own logic as much as possible , Check external calls and handle exceptions （exception handle）.

In the above case in , There are two problems ：

1、 Calling the database does not check whether it is successful ;

2、 After calling the database, there is no manual release of resources , This is likely to cause memory leaks .

Show constraints ： Simple and direct code style

In defensive programming , We advocate the use of “ The dumbest ” The way to write code , Try to use less grammatical sugar or implicit conventions .

For example, many interview questions will be encountered "a++ = b++", It is not advocated in defensive programming , It's better to write it in "a = b; a++; b++", Although the code is two more lines , But the meaning is clear , And easy to understand .

Another case is to use display constraints . such as ： multi-purpose const final static, Avoid using select *, Add the table name before the field name . In the above case in ,"SELECT id, grade, name, gender FROM students WHERE name="  Inside name You should add the table name : students.name, because name yes mysql Keywords in .

Reduce dependence ：write once, run anywhere

"write once, run anywhere" yes Sun Companies use it to show Java The slogan of the cross platform feature of programming language , This in itself is a reflection of the concept of defensive programming , That is, reduce the dependence on the environment in the code , Make sure the external environment has changed , The program still works .

In our project , The typical problem is localization . Localization often involves the adaptation of databases , Then in programming , We need to consider the decoupling of business logic and underlying data calls .

Another example ,"i++ != j++"  The results are different in different compilers , This is also what we need to avoid .

Silly comments

The code is for the system , Notes are for people to see . If you want the code to be readable , You should treat yourself as a fool to add comments .（ This and clean code  Different ideas ,clean code Advocate that code is annotation , Personally, I think this is an idealized situation ）

But notes are not nonsense , Good comments should appear in ： Complex business logic 、 Unconventional writing 、 Where there may be a pit 、 Temporary solutions 、 The core classes or methods in the project . Writing notes is a necessary skill for an excellent engineer , You can refer to the notes on many excellent projects .

Contract programming

Contract programming （Contract Programming）, seeing the name of a thing one thinks of its function , The boundary of each method has been determined in the design stage , Include the parameters of each method 、 Return value , And their types and all possible values . This term was first used by Bertrand · Meyer Yu 1986 in . He designed Eiffel Programming language to implement this programming method , stay 《 Object oriented software construction 》（Object-Oriented Software Construction） In a Book , Two subsequent versions are proposed .

Contractual programming emphasizes three concepts , Preconditions , Post conditions and invariants . These concepts are actually born out of Eiffel Some characteristics of language , Not familiar with Eiffel Students will feel a little obscure .

• precondition ： It is expected that all client modules calling it will guarantee certain entry conditions , For example, non NULL、 Not 0 Other requirements ;

• Postcondition ： Ensure that specific properties are given when exiting , For example, the database connection will be released when the program exits ;

• Invariant ： Assume at entry that , And keep certain properties on exit .

Contractual programming is a more optimistic programming idea than defensive programming , Emphasize conventions and assertions , Students who want to know about contractual programming , You can move ：https://www.eiffel.com/values/design-by-contract/introduction/

Avoid over design

Excessive defensive programming , It also brings new problems ：

• Prevent impossible mistakes , As above case Shown , For the results returned by the database , use rs.next() You can judge whether there is value , It doesn't need to be right rs Carry out non null Judge ;

• Too much defensive code , It will make the whole program appear bloated 、 Difficult to maintain , The code is full of judgment and non business code ; The performance of the program will also be affected ;

• When there are a lot of exception catching and handling in the code , It may cause the abnormality to be swallowed , Not reported normally .

summary

Defensive programming is a safe programming idea , In essence, it requires developers to have a dialectical attitude and awe towards code and online environment . It goes through the following ways , So as to improve the robustness of the system ：

• Improve the quality of the project —— Reduce bug And questions ;

• Improve the readability of the source code ——  The source code should become readable and understandable , And can withstand code review;

• Enable software to handle unexpected user actions through expected behavior .

As an excellent developer , You can't place your hopes entirely on testing , Test-driven development , It's about designing 、 The development phase , Have a full understanding and consideration of the anomalies and boundaries of the system , This is the thinking that defensive programming brings us .

appendix ： Defensive programming checkList

General matters

• Whether the subroutine protects itself from harmful input data ？

• Do you use assertions to illustrate programming assumptions ？ Does it include pre conditions and post conditions ？

• Whether the assertion is only used to explain what should never happen ？

• Do you specify a specific set of error handling techniques in architecture or high-level design ？

• Have you specified in the architecture or high-level design whether to make error handling more robust or correct ？

• Have you set up barriers to contain the possible damage caused by mistakes ？ Whether it reduces the number of other code that needs to pay attention to error handling ？

• Did you use the auxiliary debugging code in the code ？

• If you need to enable or disable the added helper , Whether there is no need to fight ？

• Whether the amount of code mapped in defensive programming is appropriate – Not much , Not too little ？

• Is offensive programming used in the development phase to make errors difficult to ignore ？

abnormal

• Have you defined a standardized exception handling scheme in the project ？

• Have you considered alternatives other than exceptions ？

• If possible , Whether the error is handled locally instead of being thrown outside as an exception ？

• Whether the code avoids throwing exceptions in constructors and destructors ？

• Whether all exceptions are at the same level of abstraction as the subroutine that threw them ？6). Whether each exception contains all the background information about the occurrence of the exception ？

• Whether there is no empty in the code catch sentence ？( Or if you use empty catch The statement is really appropriate , So is it clear ？)

Safety matters

• Check whether the code harmful to the input data also checks for intentional buffer overflow 、SQL Inject 、HTML Inject 、 Certificate overflow level 1 other malicious input data ？

• Whether all error return codes have been checked

• Whether all exceptions are caught ？

• Whether the information needed to help the attacker break into the system should be avoided in the error message ？

The main points of

• Errors are handled more in the final product code than “ Garbage goes into , Garbage out ” It's a lot more complicated .

• Defensive programming techniques can make errors easier to detect 、 Easier to modify , And reduce the damage of errors to product code .

• Assertions can help people find mistakes as soon as possible , Especially in large-scale systems and high reliability systems , And rapidly changing code .

• The decision on how to deal with erroneous input is a key error handling decision , It is also a key high-level design decision .

• Exceptions provide an error handling method that is different from the normal flow of code . If you pay attention to abnormal use , It can be a useful supplement to programmers' knowledge toolbox , At the same time, trade-offs should also be made between exceptions and other error handling methods .

• The restrictions on product code do not apply to software under development . You can use this advantage to add code that helps you troubleshoot errors faster .

Author's brief introduction

Cloud Intelligence Architecture Department , Long term commitment to the construction and development of engineering architecture in the field of intelligent operation and maintenance , Build high performance 、 High availability 、 Highly easy to use operation and maintenance engineering framework , Raise the company's technical waterline .

Open source benefits

Cloud intelligence has become an open source data visualization platform  FlyFish . By configuring the data model, it provides users with hundreds of visual graphics components , Zero coding can achieve a cool visual large screen that meets your business needs .  meanwhile , Flying fish also provides flexible expansion ability , Support component development 、 Customize the configuration of functions and global events ,  Facing complex demand scenarios can ensure efficient development and delivery .

Click the address link below , Welcome to  FlyFish  Like to send  Star. Participate in component development , There are ten thousand yuan in cash waiting for you to get .

• GitHub  Address ： https://github.com/CloudWise-OpenSource/FlyFish

•  Gitee  Address ：https://gitee.com/CloudWise/fly-fish

• Ten thousand yuan cash activities ： http://bbs.aiops.cloudwise.com/t/Activity

Wechat scanning identifies the QR code below , remarks 【 Flying fish 】 Join in  AIOps  Community flying fish developer exchange group , And  FlyFish  project  PMC  Face to face communication ～