11 Tips for Improving program sharing _ related skills

There are many reasons why we should write clear, readable programs. The most important point, the program you only write once, but later will be countless times to read. When you look back at your code the next day, you're about to start reading it. When you show the code to someone else, he has to read your code. So spend a little more time writing, and you'll save a lot of time reading it.

Let's look at some basic programming techniques:

1. Try to keep the method short
2. Never use the same variable for a number of different purposes.
3. Use a self-describing variable name and method name
4. As much as possible, define the variable as close to where it is used.
5. Reject Mysterious numbers
6. Be friendly to your language
7. Don't go against the routine.
8. Beware of premature optimization
9. Active refactoring of tested programs
10. Don't be overly obsessed with skill
11. Learn Knowledge by learning examples

Now, let's start each small point in detail.

1. Keep the method as short as possible

Although many people follow this rule, it is still very important. The way you write can always be put down in one screen. If you need to scroll the screen, it will distract you and you won't see the whole context. The best length is 5-20 lines, depending on your situation. Of course, Getters/setters is usually a line of code, but rather than a real method, they are just access tools.

2. Never ever use the same variable for many different purposes

A variable should always serve only one destination. By making variables often quantifiable (in C + + const , Java final ), the compiler is able to optimize the compilation and make your code bold enough to express that the variable is immutable , and your program will be more readable.

3. Use a self-describing variable name and method name

Your code should, for anyone, just look at it and know what it is. Try not to use shorthand unless you have a special habit, like the following:

 src - source 
pos - position 
prev - previous 

If you think descriptive names are not so valuable, compare n, ns, nsisd and numTeamMembers, seatCount, numSeatsInStadium .

4. Define the variable as much as possible near the place where it is used

When building a house, you don't want to put a hammer in someone else's yard. You want to keep them as close to hand as possible. The same is true of defining variables.

int foo = 3; 
int bar = 5; 
// 一大段使用“bar”的代码， 
// 但没用到“foo” 
// ... 

baz(foo); 

This piece of code can be simply a form of refactoring

int bar = 5; 
// 一大段使用“bar”的代码， 
// 但没用到“foo” 
// ... 

int foo = 3; 
baz(foo); 

It does become a problem when you put a variable's declaration and the first time you use it too far apart (more than one screen). Remembering contextual relationships can be difficult, and you need to scroll through the screen to find out where the variable is.

5. Reject Mysterious figures

When you want to compare something to a constant value, remember to define this value as a constant . Nothing is more troubling than guessing the code that your co-worker wrote:

il < 4384 

How does it feel to change a form?

inputLength < MAX_INPUT_LENGTH 

6. Treat your language with kindness

Learning a new language is a fun thing, and you can learn a new way to complete a task. When a person who is already a professional in a language learns another language, there is a big negative effect. For example, you are a Java developer trying to learn Ruby. You should learn how to solve problems in Ruby, rather than using Java to solve problems.

When you need to repeat 5 times "Hello world! "When, in Java, you might do this:

for (int i = 0; i < 5; i++) { 
System.out.println("Hello world!"); 
} 

In Ruby, you may be tempted to write:

for i in (0..5) 
puts "Hello world!" 
end 

This looks fine, but there's a better way:

5.times { puts "Hello world!" } 

7. Do not reverse the routine

Each language has its own different conventions. Generally speaking, the most people listen to is the Java coding specification. Let's take a look at some of these customs norms:

• The method name should begin with a lowercase letter, followed by a word in uppercase letters ( veryLongVariableName )
• Class names should all be connected by using a word in the first letter.
• The constant name should all be capitalized, with an underscore attached ( MY_CONSTANT )
• The opening brace should be on the same line as the IF statement

Break these routines only if you have the necessary reasons not to violate them easily because you are not happy. If you're just changing some of these habits on the team, that's fine, but when you take your code and share it with other programmers who don't have it, the problem comes.

8. Beware of premature optimization

Premature optimization is the root of all problems, at least on television ... The first thing you should care about is writing code that is easy to understand. The program written at first does not require fast. unless your program is slow, it's too early to talk about optimization. If you want to optimize something, you first need to know what the problem is. That's why we need to profilers this tool.

Trying to optimize a program without knowing where the problem is is bound to spoil the program, or at least your code will lose readability. If you think some places are slow, don't rewrite the code blindly, you should find the slow evidence first .

Don't be silly to solve problems that don't exist at all.

9. Actively reconstruct the tested program

Nothing is going to be perfect. Even if you feel like you've actually written a perfect piece of code and look back a few months later, you might be surprised how stupid it is. “

A good way to improve a program is to refactor it, but after the program is tested. You first have to make sure that the program is well run and that you can do it through automated testing or manual testing.

At the beginning, you need the program to be available. Don't expect to write the perfect program at the first time, you just have to write it out and use it. And then refactor it to make it perfect. For those of you who know about test-driven development (TDD), you'll be familiar with this. The key here is that you get used to refactoring things like that. Refactoring can be a lot easier if you're using a powerful integrated development tool like IntelliJ idea.

After refactoring, you may be able to make some bugs that can cause problems with certain functions. That's why it's about writing automated tests. Whenever you refactor, just run all the test cases and you'll know exactly what went wrong.

10. Don't be overly obsessed with skills

When I first read about design patterns, I felt I had found the holy Grail. These well-designed ideas work so well that it makes your design easier to understand, because you can simply say "I'm using the Observer pattern" rather than explaining it to you from the beginning. So, is there a problem? Everything seems so natural and simple that you start using design patterns wherever you are. Why not make this class into singleton? Why not go and create some more factory classes?

So a 80-line script, you end up using 10 classes, 15 interfaces, plus a bunch of paradigms and markers. 97% of the code doesn't do anything. Design patterns are a very useful tool for simplifying your design, but that doesn't mean you should use it wherever you can. you should use them, but you can't abuse them.

11. Learn by learning

Programming is a process of learning new knowledge. When you learn a new library or a new language, you may be impatient to throw away the old code and rewrite it with what you've learned. There are many reasons why you shouldn't do this.

Adding a new class library or framework to an existing application is the case. Just say you wrote a JavaScript Web application during which you found jquery. Now you're suddenly eager to throw in your JavaScript program and write it back in jquery, even though you've never used it.

The best way to do this is to use jquery to write some simple examples, and in this way you will learn all the knowledge you'll be using in your application. Need Ajax? Do some small examples outside of your project, and when you fully understand it, throw away the example and apply it to your product.

If you are very concerned about programming technology, I strongly recommend that you read the book "Code Encyclopedia" written by Steve McConnell. It will change your understanding of programming forever. :)