Dragon 18 Palm

How to write high-quality code, each developer has their own understanding. I have roughly collated the following 18 tricks for your reference. Just like martial arts, every kung fu need a name, just a personal comparison like the Dragon 18 Palm, and there are just 18 strokes

The first trick: Develop a good habit

In my first year of work, I was fortunate enough to join a good team and a good leader. I remember the first thing he said to us: the formation of a good habit is very important to your future work, and of course it requires you to cultivate it from the start and persevere and persevere. And a lot of what we're talking about here, or most of it, can be part of the good habit.

The second trick: Standardize your code

No rules, inadequate surrounding area. The code follows a uniform format specification, first convenient for future maintenance, and secondly for easy handing over to others. It is important for a project team, a company, to read clearly and be clear and to look neat and tidy. The way to check is also simple, if the entire project code finally looks the same as the style of the person, then prove that you followed the specification. Just like the exams in our reading age, your examination papers are neat and clear, and you will definitely be given extra points. Here we give an example of how to standardize a class in code. First, the definition of member variables need to be put together, not a few on top, several in the middle, a few run down to the next, then the method definition in the class, and finally the Get/set method of the member variable. At the same time, it can continue to be subdivided according to public, protected, private3 species.

The third trick: a reasonable comment on your code

Many people write code do not like comments, or feel that the project time is tight, busy to achieve the finish, or feel that there is no need, anyway can read.

Another part of the people like to write the program after the comments, a bit of the concept of homework.

Only a small number of people will be in the code before the beginning of the idea, write out the code of the steps, the comments of each branch, and then fill the implementation code below the comments.

Obviously, the third is the most correct approach, is the so-called: The soldiers have not moved, fodder first. Of course it's the hardest, but if you get used to it, it's soso.

The rate of comment for a qualified code is generally above 30%.

Four strokes: Do not write duplicate code

I think each of us developers should think of it as the Monkey King's magic Spell, always read several times to remind himself repeatedly. Duplicate code is definitely the first feature of the Spam code and is the biggest feature. Copy will be very cool, but often there is a queer, once the error, it means double the workload and continuous uncontrolled.

The highest goal of not writing duplicate code is to not write two lines of the same code, of course, there is only a theoretical possibility, we only need to do not write two copies of the function of the same or similar code. This degree I think you can master.

Five strokes: Do not write too many parameter methods

When you have more than 5 method parameters, you need to consider whether the design of your method is reasonable. Do you really need so many parameters? Is it possible to streamline? If you really have to, then you also have to change the time, encapsulate the object to pass it, not only reduces the number of parameters, but also provides the possibility of infinite expansion later. At the same time the user does not have to hard remember the order of the parameters.

Six strokes: Do not take off the pants fart thing

It's pointless to take off your pants and fart, I don't think anyone will do it. When we encode, the same is true, and meaningless code doesn't have to be written.

When we develop, we often use copy to achieve some functions, but after the copy comes, it will introduce a lot of things not to be used, the code left over there is completely meaningless, can be deleted.

In addition, we often inadvertently make some of these errors: write if else if else judgment statement, the conditional judgment will be duplicated, the code inside the branch may never be executed, these are in fact we did not clear the idea before the code, which is the importance of the code comments we said earlier.

Too much consideration of the possibility of the future: sometimes when we consider the scalability of the code, we will enter a misunderstanding, that is, the concept of excess. Bring in a lot of possibilities that are not present, which may never be used, and it is completely unnecessary to write in the present.

The seventh trick: limit your valve.

Open water, close the door to put the dog, pay attention to is a into and out, write code is the same.

In small terms, our approach, the consideration of participation needs to be careful enough, fine enough, the location of the argument needs to be limited to the tail of the method. Many people like to use return in the middle of the method to terminate the operation of the method. For example, to do some check, not satisfied on return, this is not a good practice, although the implementation of the above is not a problem, but to ensure that the unification of exports more important.

For example, if you need to record the execution log, or if you need to do something extra at the exit of the method, then the unified export will be very convenient, otherwise you need to deal with each return.

In large, the interfaces we open to external use are limited to one level. This time with the proxy mode, façade mode will be a better practice. Too many features open to the outside, sometimes it is difficult to grasp. With the agent to do a layer of encapsulation, and then unified façade, will make the code out of the entrance more controllable.

The eighth trick: put your code right

Some people say: aha, I learned core Java, I will have all the foundation, I can go to the code of the world free roaming. This cannot be said to be wrong, but if you only consider the realization of the function to do things, it is the same as the base brick. No wonder we programmers often = = plasterer. In fact, in addition to the implementation of the function, you have to consider a lot of things, the correct placement of your code location is very important. Check your method to see if the implementation logic inside should be in the method of the name, check your class to see if the method should be placed in the current class, check your project, and see if the class inside should be in the project. Layer by layer Check, you should find out how many problems your code has. This sometimes is the result of human process thinking, from the big aspect is that we are not abstract enough.

The nineth trick: more for your users to consider

Do anything if there is no service object, it loses its own meaning, the same code is the same. Or if you are doing a framework to make a product, then you are dealing with an ordinary developer, or you are doing a project, then you are dealing with a customer in our usual sense. No matter what you are dealing with, a good starting point is very important: more for your users to consider, also say we often say, customer first. Here we take the writing tool method as an example: when you write a very good tool component, finally you have to consider is the Open API interface, which interface to open which interfaces, the parameters of the interface. All of this requires you to think about it as well as possible from the user's point of view. Whether it's a Java overload, or an adapter in design mode, it's all about the idea of making your users as simple and less of a thing as possible.

Tenth trick: Strengthen your understanding ability

More than 10 years of Chinese study, I do not know how much impact on your current job. In my opinion, the most important role is to develop our understanding ability. Understanding ability is important for developers:

Fast understanding of customer meaning, can ensure you good communication

Correct understanding of requirements, can guarantee the correctness of your direction

In the same way, good understanding can make it easier for you to read other people's code.

11th Trick: Design mode

The appearance of design patterns is to solve some common problems, it can make your code more beautiful and efficient. 23 Design patterns, more is a concept of ideas. When we learn, we can start with simple, easy-to-use and often-used ones. such as factory, single case, gradually we can try agent, adapter, synthesis, façade, finally we can use some more complex observers. In order to better understand, when you finish the whole, you can learn the anti-design mode, it will allow you to choose the design pattern application scenario when more fit, reasonable.

The 12th trick: Remove your code

After 5 years of working, I finally understood that one of the most important indicators of evaluating a piece of code was whether it was easy to disassemble. In simple terms, it is the coupling. Here the coupling is divided into internal coupling and outer coupling. What we generally notice is the outer coupling, that is, between our code and the external code. In fact, inner coupling is more important at some point: the relationship between our code internals. For example, you have made a persistent service tool that covers 3 pieces of content: Adding and deleting, scripting, data definition. The entire persistence service does not depend on any external content, or the level of dependency is cut to a line, so the external coupling control of your code is very good. This time we have a colleague who wants to use a data definition function, but it wants to add a lot of personalization in it, that is, he just want 1/3 of the content, this time your code can be very good disassembly, without destroying the other parts of the balance, your internal coupling is the standard.

The 13th trick: Check the tool to help you busy

After code, use some simple static check tools, such as Checkstyle, Fingbug, etc., you can easily check out the format of your code, as well as some hidden vulnerabilities.

You can also do the next unit test to make your code more robust.

The 14th trick: warm so know the new

Personally think the best trick, every once in a while, go back and look at the code you wrote earlier, can be a week, one months. Take care of the code you write as your own child, if you don't have a child, be a boyfriend or a friend, or a small partner. In short, we have to be passionate about it, and the code is actually alive. A good code may survive for a long time, one year, two years, ten years. But a dross estimate will soon be overturned and reconstructed. Each time you review you should be able to find some of the problems in your code, so gradually you 2 people are growing.

The 15th trick: Learn to stand on the shoulders of giants

Sometimes a lot of features, degrees Niang and Google artifact can help you easy to solve, so there is no need for their brains, reinvent. Because there are already giants to help you climb higher, why not to enjoy it. But will you use the giant correctly? Do you want to use it without understanding it after copy? There is no point in encountering problems later.

Because I am a framework, so I encounter this kind of problem will be more. Because there are always people complaining to me about the complexities and risks of updating the framework because of the problems that arise after the update. In fact, there are two reasons for this: first, there are some problems when the framework is released, and the way we use the framework is not correct.

The right foot on the shoulders of giants first you should do the following several things:

1. Be familiar with the content you use, this is the minimum. such as what you use, these need to be at your fingertips.
2. It is better to limit the level of your application, which is another case of the valve we have mentioned above. For example, if you apply a third-party feature, then when you access your project, do you write directly to your business process code, or do you package it once? Obviously the latter is a correct approach. While it will take you some extra time, not only can you improve reuse, but you will have to pay much less once you have implemented the way or version of the upgrade.
3. Correctly grasp the degree of personalization

Sometimes you need to use the framework of a function, but there are a lot of unsatisfied, this time will generally consider the implementation of personalized code. The general approach is simple and rough: Copy out the original code to modify.

In fact, a good practice is to consider first, whether this personalized content is the framework of the original function of the complement and refinement, if so, it should be submitted to the framework to solve, or to implement the submission framework to integrate and then reuse other projects, which means that the function is subordinate to the original function.

The second approach is to consider doing some extended modifications to the original functionality to support: for example, with some reflection-out interface processing. The content of the personalized business is still self-made, but the original function of the subordinate framework can be reused.

The third approach is inheritance, the same principle as the second one.

Finally, consider the copy code to make changes.

Based on the original function to do, the biggest advantage is that once the original function is optimized and upgraded, then your content will be seamlessly upgraded. Otherwise if you want to come back in the future, the cost of the flower will be very big.

The 16th trick: start cutting your code.

When we're still wheezing to write a lot of code for some of the new features, many of them are doing the exact opposite of you, they're cutting the old code, and sometimes they can rely on thin code to implement new requirements. Another term for chopping code is refactoring.

17th trick: A detailed and beautiful guide

Spring and Autumn time, there are a lot of lobbyists, light persuasion can gongchenglvede, retreat resist enemy, it is obvious that the importance of speaking out. So not only do you have to work hard, but you also need to be able to show what you do. As a coded programmer, more likely to rely on writing, this writing is generally a guide, plainly speaking is a document. Large to the entire system operating manual, small to the function module API. Just like marketing, you need to recommend what you do to get people to realize the value and benefits of this stuff before someone pays for it.

So, strengthen your documentation skills, Sao years.

The 18th recruit: No recruit wins a recruit

See Martial champion Su begging son know, finally Stephen Chow down in the ground, watch the Dragon 18 palm cheats, wind blowing scroll, the final 17 strokes fusion became the 18th palm: the dragon pendulum tail. The same is true of our code, and when you are able to integrate everything, you do not need to be so many routines, because you have become accustomed to nature, your every move is already very good moves. Of course, for this kind of state, I have been on the road.

Dragon 18 Palm