Various popular programming styles

Over the past N years, I’ve met a lot of developers using awkwardly different styles, here are some I know, do you know others?

Shotgun Programming

This style of programming is one where the developer uses a very casual approach to the code. “Well, this method call went wrong …… then I’ll try to change the passed parameter from false to true!”, but of course it still goes wrong, so our programmer will do something like, “Well, then I’ll comment out the or some other more arbitrary way of handling it until we finally get the call to work. Or some programmer next to him points out a correct method.

If we put a regular programmer and a lucky programmer together, the regular programmer can immediately go crazy and minimize the regular programmer’s IQ. Two crash programmers should not do twinning programming together, because their destructive talents can cause worse damage than just one.

Hitting the jackpot programming

This is a somewhat gentler approach to programming than shotgun programming, and I believe that this approach will probably be the one that most programmers will use. This type of programming often occurs when programmers don’t know exactly what they are doing or the nature and reality of the program they are writing, but can make the program work. They are writing programs in a hit-and-miss way, and some times they start modifying the code sparingly without even knowing the cause of a particular error. Once a problem occurs, they use two paths: 1) stop, understand the program, and find out what went wrong. 2) use shotgun programming to start fixing the problem.

Test Driven Development (TDD) is a programmer that can be used to save millions of crashing programmers. So, they have a more NB excuse: As long as my program passes the test, what else do you have to say? Don’t scold me, Test Driven Development is a good thing, it’s mainly used to control the problems caused by crash development.

Cargo-Cult Programming

The term Cargo Cults comes from the indigenous people of certain small islands in the Pacific Ocean during World War II. During the war, the United States used these islands as supply depots in the Pacific. They built their own airstrips on these islands to transport war supplies. The natives on those islands had never seen an airplane before, and when they saw one, they thought it was pretty awesome and could bring all kinds of goods and food to those white people. When World War II ended, the natives built airstrips modeled after them and built towers out of bamboo. And there they were, expecting planes to bring them goods and food.

Cargo Cult programming was a very popular programming method, and programmers who used it would learn from other programming masters, although they didn’t know why the masters did it, but they thought it would make the program work. As an example, there were a large number of programmers who used EJBs and Entity Beans excessively in the first year of J2EE.

Programming by Carving a Boat

Carving the boat is a very popular Chinese fable. This style of programming is very common in programmer’s circles. For example, one day you find a null pointer exception, so you go to the place where the null pointer exception was generated and simply put in a judgment:

if (p != NULL)

Yes, a fix like that gets your program working, but you’re not really solving the problem. You’re just noting where the sword fell on the side of your boat, which only hides the problem and ultimately just makes your program behave in a godforsaken way. You should find the reason why the pointer is empty and then fix the problem.

Design Pattern Driven Programming

As the name of this kind of programming says, this style of programming uses a lot of design patterns. In your program, there are design patterns everywhere, and your code is full of Facade, Observer , Strategy, Adapter, etc. etc. So, the business logic that your program has to deal with is so disrupted by these design patterns that it is unreadable, and in the end, it is not clear whether the business requirements start over or the design patterns are important. In short, the actual business requirements of the program logic is confused beyond recognition by the various design patterns.

Detective type programming

When resolving a bug, a detective programmer investigates the cause of the bug. Then, it investigates the cause of the reason that triggered the bug. Then, it will analyze the causality of whether fixing the code will cause other code to fail. Then, he or she uses a text search to find all the code that uses the change and continues to find the higher-level calling code. Finally, the programmer writes down 30 test cases for different scenarios, even if they have nothing to do with the bug, and finally, the programmer has enough confidence and fixes a spelling error precisely.

Meanwhile, one other normal program fixed the other 5 bugs.

Slaughter-style programming

Programmers who use this style have an uncontrollable and extreme urge to refactor their code. They will refactor almost all of the code they handle. Even on the eve of a Release, while fixing a few misspelled bugs, he will modify 10 classes, refactor 20 other classes that are related to those 10 classes, and modify the build script of the code, as well as 5 deployment descriptors.

(end)