Contract Programming vs Defensive Programming

background

The origin of the matter can be traced back to a huge stellar explosion hundreds of millions of years ago. Sorry, I recited the wrong lines. It started from the discussion of interface return data a few days ago and the discussion of local data structure of courseware a few months ago. To put it simply, when encountering an exception to the agreed content, we should make compatibility processing internally in the program or throw it out.

For example, if we want to parse a piece of json, and the format of this json is agreed to be either normal format or empty, then once the method that returns json returns an abnormal value that is neither normal format nor empty, how should the program handle it?

Xiaohua: Once a contract exception is encountered, the program must handle it in a compatible manner and must not let the program crash. Xiaofa: Once a contract exception is encountered, it must be thrown to inform that the contract is wrong and find out the specific cause of the error.

I believe that all programmers have encountered this problem. Let's take the most common example, NullPointerException. If we want to get a field from json and suddenly find that NullPointerException occurs, some developers think it is a data problem, so just change the field in json to be correct; some developers think it is a program problem, and think that the program needs to make a non-null judgment before using it. I believe that both types of programmers have their own reasons. The first type of program is concise and clear, and the code logic is clean, but once an error occurs, it will crash. The second type of program is durable, no matter how wrong your data is, I can still not crash, but there are non-null judgments everywhere in the code, which is bloated and repeated.

To be or not to be, that is the question!

Defensive Programming

While we were arguing about this issue, a colleague named Kang suddenly threw out a brick (Code Complete 2, nearly 900 pages, equivalent to 3 volumes of Android Heroes). I thought he wanted to smash it in my face. Just as I was about to dodge, he turned to the eighth chapter of the brick, and a few big words caught my eye - "Defensive Programming".

He is indeed an experienced driver. He can actually understand defensive programming from defensive driving. What happened to the saying that you should not drive when programming, and not program when driving?

I don't know if this author is good at programming, but I know that when it comes to driving, he is definitely better than Mr. He!

OK, Code Complete provides us with a definition - "defensive programming". To put it bluntly, it means "humans are unsafe and untrustworthy. Everyone makes mistakes, and the code you write should take into account all possible errors so that your program will not fail due to the mistakes of others."

In the book, the author tells us that the program needs to be compatible with possible erroneous inputs. For example, in a division function, you must determine the case where the denominator may be 0, and return an error prompt to the caller. In addition, general high-level programming languages ​​provide two ways to handle errors: "assertions" and "exceptions."

assertion

Assertions are a type of code used in the development phase to allow the program to perform self-checks during runtime. If the assertion is true, the program runs normally. If the assertion is false, the program exits abnormally. Wait, isn't defensive programming supposed to be compatible with exceptions? Why does it exit? In fact, the author means that assertions should be made first and errors should be handled later. Assertions are in the development environment and will not be made after the official launch.

But in fact, this is a paradox. The error handling code in the development phase is intercepted by assertions in the development phase, but the error handling code is also written by people, so how to detect "errors that may occur in the error handling code"?

abnormal

When there is a problem with the code, you can notify it by throwing an exception. If you cannot handle it, you can hand it over to the outside world for processing. I won't say much about this. After all, for most codes, if there is an exception, the simplest way is to try catch. I have even seen all the codes directly try catch. How much do you distrust humans?

So I thought that if I used defensive programming for a long time, I would start to doubt my life. Sure enough, a few pages later, the author also gave some suggestions.

To borrow a line from Doctor Strange - "You actually wrote the warning on the next page after the spell!"

In short, defensive programming means looking at all the codes with a skeptical attitude, but this is slightly different from the topic we are discussing. The topic we are discussing is "there is already a contract, but the content outside the contract is returned."

Contract Programming

While we were discussing, five words suddenly floated in the sky - that's not a problem, oh no, it's "Contract Programming".

This seems a bit similar! Let's take a brief look at what contract programming is. Simply put, a contract acts on two parties. Each party will complete some tasks to facilitate the conclusion of the contract, but at the same time, each party will also accept some obligations as a prerequisite for the formulation of the contract. If any party ignores the obligations that must be fulfilled, the contract fails.

Contract programming requires us to check the contract in "preconditions", "subsequent conditions" and "invariant conditions". Similarly, for example, if the parameters are incorrect, the contract will be torn up immediately. Many new languages ​​now support this, such as Swift, which supports constraint checking of parameters, which is a kind of contract-like programming.

The contract is a condition to ensure the normal operation of the program. Once the contract is broken, there is only one reason, that is, there is a bug in the program. For example, a data field must be guaranteed not to be empty when I process it. So who can guarantee this? It must be my caller (or other modules). Therefore, once a problem occurs, the caller should check to ensure that it is not empty when calling.

This reminds me of some things when I first started programming for Japanese people. The Japanese style of doing things is notoriously cautious and detailed. When designing each method and function in detail, the parameters, return values, their types and all possible values ​​have been designed. There are clear boundaries between each method. If your method causes an error because the parameters passed in are not within the design range, you can go to the caller and ask him to call it according to the design. I have to say that this should be the best practice of contract programming. There is actually another reason why Japanese companies generally use this method, that is, it can strictly distinguish responsibilities, so that everyone does not have to do "difficult coding" to accommodate the mistakes of others. Everyone handles their own affairs according to the contract and makes those who damage the contract bear the responsibility.

To extend this further, this is very similar to the current "interface-oriented programming". Between the two modules, the calling and processing interfaces are defined, and the other party does not need to care about the specific implementation. It only needs to install the protocol interface for development. However, the interface alone is not enough, and a contract is also needed to make further constraints, such as constraints on parameters and return values.

Coincidentally, in "Code Complete", the author also proposed "offensive programming", which is actually similar to contract programming.

Utopia

OK, the dream is over, let the sun shine into reality. The above two programming methods are both very idealistic programming, but in general companies, whether it is defense or contract, it is difficult to implement, such as the interface between the front-end and the back-end, the communication between colleagues in different departments, according to contract programming, no one cares about your contract, according to defensive programming, the code is terrible, and it is easy to miss the defense. So what should we do? I think that if contract programming can be promoted at the company level, first of all, it will improve development efficiency, let everyone be responsible for the code they write, establish a good trust relationship between developers, and also reduce unnecessary communication costs and energy. But at the same time, necessary defensive programming is also indispensable, which is the premise of ensuring the robustness and stability of the program. How to say it, the Chinese people have inherited the tradition of thousands of years - the "golden mean", contract or defense, depending on the situation, this is the art of balance.

warn

Please read this article defensively. Everyone makes mistakes. Feel free to leave a message to communicate.

Once this article is published, it is very likely to trigger a melee between the two sides, red and black, Scourge or Guards, Alliance or Horde, Choose your side.