This article was first published from "MOOC". If you want to know more about IT dry goods and hot news in the programmer circle, welcome to pay attention to "MOOC"!
Developing a good programming habit can benefit you throughout your career.
For example, make comments to make it easier for yourself and others to understand the code; name variables in a scientific way instead of doing whatever you want; standardize the test instead of dragging the test until all programs are completed, and so on.
Here are some good habits worth sticking to. Programming is a job full of creativity, but it is also a job where details determine success or failure. You may spend 80% of your real work time dealing with trivial problems.
Therefore, avoiding their frequent appearance as much as possible will make your career easier and lead you to success.
1. Technical level
1. Primary skills (technical details)
1) We know that in C-like programming languages, int and bool can be converted to each other. ** Therefore, both a = 1 and a == 1 can be used as the criterion of if. Many novices will treat "=" as "==", and this will not cause an error. So this kind of error is more difficult to find. A little trick is to write the judgment condition as: 1 == a, so that if it is written as "=" by mistake, it will cause an error at the grammatical level of the compiler, so that the error will be found immediately.
This technique only plays a role of attracting ideas. There are many types of programming languages, but almost every language can find some techniques similar to this in C-like languages. This kind of technique can sometimes save a lot of time when used well.
2) Be good at using bit operations to improve operating efficiency
When the amount of calculation is large, being good at using bit operations to replace some ordinary operations can often improve code efficiency. For example, a * 2 can be written as a << 1; for another example, when judging whether a number is odd or even, a & 1 is much more efficient than a % 2.
2. Intermediate skills (code readability)
1) Use of spaces
Many novice programmers haven't realized how much a small space can do: a=b+c and a = b + c --- it's one thing for a computer, but it's not for a programmer. Totally two different things. When you are faced with thousands of lines of code to read, you must thank the programmer who uses whitespace.
2) Code with a consistent style
The code style includes the style of the code itself and the naming of the file. In short, everything written into the computer by your hand through the keyboard should maintain a consistent style, including file names, variable and function names, indentation, etc. Experienced programmers must have a deep understanding of this point. A consistent code style will not only facilitate you but also the people who read your code.
Let’s take a simple scenario. There is a two- or three-year-old child among your relatives and friends. He said two words "gu hu". As long as you understand the specific meaning of these two words, after his mother's translation, you suddenly realize: Oh, it turned out to be "uncle". This is the same as the code with different styles. It is difficult for you to understand its meaning, and it takes a lot of time to interpret the thinking of the person who typed the code.
3) Naming should have meaning
This article does not need much explanation, which one is clearer, a = 1.2 or price = 1.2. In principle, it is better to make variable or function names longer than vague or meaningless names.
4) Learn how to write notes
When to use annotations, this is an old question, and there is no specific standard for it. There is a saying: In a sound code, the commented part should be one-half to two-thirds of the code itself. Xiaomu doesn't quite agree with this statement. The comment should depend on the situation, but this also shows the importance of the comment. Never believe that as long as the variable name and function name are well named, there is no need to comment such remarks.
According to experience, when the logic is more complicated and where it is easy to step on the pit, comments must be written. As for whether each function needs to write comments about the return value and parameters of the function, it needs to be analyzed in detail. If the project requires you to write, then you don't need to ask too much; if the project does not have such a hard requirement, then it is best to have comments for the more complex functions that are often used by everyone. In this way, everyone who uses this function can quickly understand how to use this function through comments.
In addition, in some places where the function body is empty, writing a line of comments will also play a positive role. for example:
void func () {}
and
void func ()
{
// nothing to do
}
When these two ways of writing appear in a lot of code, it is obvious that the second way of writing is much better than the first.
But at the same time, it should be noted that writing comments also has a price. When you modify the code, the corresponding comments must also be modified, which will increase the workload virtually. If you accidentally forget to modify comments, it is likely to confuse people who read the code, that is: comments also need to be maintained. So remember not to abuse annotations.
3. Advanced skills (debug)
1) Use the [control variable method to debug
Many novices are often unaware of the fact that writing code itself doesn't take too much time, what really takes time is debugging. It can be said that the speed of debugging can directly reflect a person's programming level. Debug skills, maybe different programmers will have different experiences, but there are only two that can really be called debug skills: control variable method + dichotomy method.
The so-called control variable method means that when faced with multiple uncertain factors, you have to artificially modify these factors so that only one uncertain factor remains. Take a look at this code:
if (func() < func2() && value > getSize())
{
// …
// …
}
When you run this code, you find that it should not have entered the if, but it came in. At this time, you need to find the problem. Novices often feel a little helpless, because there are two judgment conditions here, which one is wrong? In fact, according to the control variable method, such a debug will be easy to find: we only need to temporarily remove a condition, let the program execute, and the error can be located immediately.
The above example is a real case. Among them, func and func2 are very complex functions, and getSize() is a function written by a friend and packaged in the library. The bug is: when the value is -1 and the return value of getSize() is 4, the part in the if is actually executed. In fact, the reason for the bug is that the return value type of getSize is unsigned int, and -1 is an int type, so -1 > 4 becomes true. In the face of such bugs, if you step by step by adding breakpoints, it will still take a lot of time to find the bug. And if func() < func2() is removed first, leaving only the following judgment conditions, then the error can be located immediately.
2) Debug with dichotomy
When faced with a large number of bugs in the code, if you want to find the bug in a very short time, you can use the "dichotomy method". for example:
// a) 1000 lines of code here
// b) You feel that the bug is probably in this position
// c) 2000 lines of code here
At this time, it is not necessary to understand the codes at a and c, but only need to understand the code at b. More precisely, we only need to know what b got from a and what b gave c.
Assuming that the code at b depends on the two values generated by the code at a, then you can directly comment out all the code at a, then simulate the two values for b, and then run it to see the result. If the bug still exists, it means that there is no problem with the code at a - at least the source of the bug is not at a; and if the bug disappears, it means that the bug originated from the code at a.
for example:
int func ()
{
// 1000 lines of code
return x;
}
void func2 (int a)
{
// 2000 lines of code
}
int a = func()
// change the value of a
func2(a)
If this code reports an error, the fastest way to locate the bug is to first simulate a parameter to func2 to see if the bug is still there. If the bug is still there, it means that there is a problem with func2; otherwise, it means that the problem lies in the previous code. If novices can learn to use this method flexibly to debug, I believe that they will soon be able to enter the ranks of "old fritters".
In fact, debugging is the same as finding a target. Only by paying attention to methods and methods can we avoid the fate of being lonely. For example:
Don't talk about programming knowledge that she doesn't understand!
You must go to her house to repair the computer!
Being able to distinguish when a girl says she is angry and ignores you doesn't mean she really doesn't want to talk to you!
……
2. Work and study level
1. Constantly review the basic knowledge of programming
For things, the most basic is often the core. Only by constantly reviewing the basic knowledge of programming, understanding the thinking system of programming, knowing what it is, and knowing why it is so, can you use it handy. I won't find the mistake for a long time and finally slap my head: Oh, it turns out that I made a mistake here.
There is a programming novice who wrote a code some time ago. The logic is this: a hyperlink requests the background, but after clicking the link, the page is refreshed, and the background request does not go. He searched for a long time but did not find the problem. Finally, let a colleague with higher qualifications see that his A label reads like this:
<a href="" onclick="getUserInfo();"/>. so changed to
<a href="javascript:void(0)" onclick="getUserInfo();"/>. After the colleague changed his head and left, he suddenly realized.
2. Systematized listing and fragmentation
Many people say that their third year of high school was the peak period of knowledge accumulation in life, because the most important task at that time was to study and recite relevant knowledge points repeatedly every day. But no matter how clearly I remember it at the time, as time goes by, many things will be gradually forgotten if I don’t review the past and learn the new after college. This is a forgetting curve of human memory.
For programming, there are too many languages and techniques, and it is impossible to expect a photographic memory. Buy a notebook, or use various cloud programs to systematically list your own programming language entries, subdivide detailed modules under the entries, and contact with excellent viewpoints, practical skills, and in-depth knowledge during work and leisure. The analysis principles can be recorded in fragments. In this way, it is convenient to browse at ordinary times. As long as you persist for a period of time, you will find that your professional skills have improved a lot. In fact, it's not just programming. In any industry, there is no genius who can reach the top without paying. Learning programming itself requires the accumulation of time and experience. On the basis of diligence, adhere to good habits and correct methodology, I dare not say whether I will succeed or not, and there will definitely be progress~
Welcome to pay attention to the "MOOC" account, we will always insist on providing high-quality content in the IT circle, sharing dry knowledge, let's grow together!