I have nothing to do on weekends, just chatting with people. I wanted to write about how to be a good programmer, but then I realized THAT I might not be able to do it myself. So being modest, I changed the title.
I will not write about methodology or feelings, which you may not get and may not like. Write a little practical this time, as long as follow, basically will not be regarded as a rookie, in the workplace will not tread on thunder.
Believe in the power of small habits
In addition to the core ability to write code and debug, there is another big difference between the novice and the great. The bull has developed a series of good habits, while the rookie has not developed good habits, and has a pile of bad habits. So when you’re a beginner, you have to have a sense of norms and habits, and develop good habits, and get rid of bad habits and get used to writing good code.
Everyone has his own habits. Let me just mention a few of them, just to give you a little bit of inspiration.
A function only does one thing
How would you feel if you took over another colleague’s code and found out that he had a function with 3,000 lines of code in it?
It happened to me, and my first instinct when I saw the code was to take the guy out and beat him up. Code, unlike other text messages, is less readable the more crowded it is. Good code, like good writing, is clear, structured, and accurate. Packing thousands of lines of code into a function is clearly old lady’s foot-wrap — long and smelly.
Everyone has a different idea of how much code should go into a function. In fact, we don’t have to be rigid, just follow a simple rule – a function does one thing. As a simple example, suppose we want to read a bunch of data upstream and plot the result of a function. Let’s make a brief analysis. On the surface, drawing is a matter, but it actually involves several steps, such as obtaining data from the upstream, obtaining the result of function action, and finally drawing. So we can completely split it into three functions, one to get the data, one to get the results, and one to draw the graph.
This makes it very clear to others and later to ourselves what each function does. If one day the boss accidentally went through everyone’s code, other people’s code has thousands of lines in a function, your code is clear, each function does what is clear, how do you think the boss?
A longer variable name
A big problem for beginners is that they tend to use very short variable names, such as A,b,c, and D. Or bd, OR AA, or whatever it is, it looks very ugly, and it’s very unreadable. Before, several students asked me to help them look at the code, the code was given to them, it looked like their eyes were pricked by needles…
Joking aside, to be honest, WHEN I played ACM, I also liked short variable names, although not so exaggerated, but generally a variable name is not very long. Of course, this is because of the need of the game, everyone is racing against time, someone else’s variable is called BTN, you are called binary_tree_node, obviously you will lose the speed of the code.
But the problem was that I kept this style after graduation, and unsurprisingly, my boss and colleagues beat me up. Everyone said they didn’t like my code style, and I insisted at the time that it was a demonstration of my code ability. Later, I read some of the code of Danniu and tried to change a style. I found it really fragrant. Although it is a bit troublesome to write (in fact, it is also ok, now there are various code completion functions), but it is really comfortable to read, the idea is also a lot clearer. So if your current code doesn’t look like this, please try to change it for your own good and everyone else’s.
Another point is that when we name can be non-standard English, even if it is not too accurate, but must not use pinyin.
Pinyin is more difficult to read than half-broken English, and using pinyin for variable or function names is a very, very low thing that will definitely make people doubt your ability. There are also some plugins on the market to help with naming, please be sure to check them out if you have this need.
Compliance with code specifications
There may not be such a thing as a code specification in the novice’s mind, but it is a necessary step from novice to advanced.
Different languages have different specifications. For example, Java and GO are popular with camel nomenclature, where all variables are camel. Python, on the other hand, may only have class names that are humped; ordinary variables and package names tend to be all lowercase and underlined. Of course, code specifications are not just naming conventions; there are many, many more. For example, the use of middleware specifications, multi-threaded development specifications, the use of databases and so on.
Why do we follow these norms? Because our development work is not just to implement the function is done, we need to expand and maintain later. Not only will compliance with the specification save you and others from future pitfalls, but more importantly, it will make your code higher quality and more professional. And there is often a rationale behind some specifications: why do sockets, threads, and database connections need to maintain a “pool”? There must be a way in, otherwise why don’t you make it easy? It also allows us to better understand the principles and details of each scenario when we follow these specifications, which is part of technical strength.
Of course, we may not do well at first, but the code specification is not that difficult, and it doesn’t take a lot of time from the moment we realize it to the moment we comply with the specification, but the benefits are huge. In my previous work, I heard that the boss gave me a poor performance because of the bad code style. I felt quite unfair. Maybe it was just a moment of negligence that left a bad impression on the boss.
Knowing how to use it is not the same as knowing
If you are a recent graduate, you will inevitably face an adjustment problem when you graduate and enter the workforce. We won’t talk about anything else, just the technical side. We certainly need to quickly learn some techniques that we have not seen or understand before to cope with the tasks and challenges in our work.
This is quite normal, and I think most programmers have experienced it when they are fresh out of school, including myself. The first few months after graduation are the hardest. We need to bear a lot of pressure and not fully adapt to the life after the transition. But as the months pass and we get used to life and learn the basic skills to be able to cope or do the job we’re doing, a potential pitfall sets in.
Some people will unknowingly stop learning, because he has enough to cope with the work. At work they may feel that their current skills in the field are sufficient, and some may even feel that their more senior colleagues are doing the same, as if they don’t have much more than themselves. That’s what I did, because I found the things I used at work to be very handy. At one point, I got a little inflated and thought I was already an experienced programmer. It wasn’t until an interview, when I was asked about the technical details of a commonly used tool and got tongue-tied, that I realized I only knew the surface, if not the surface.
Of course, in our work, many technical requirements are just able to use, you can use enough, there is no problem. I don’t think every technology we use needs to be thoroughly researched, but we need to be aware of our strengths. Which ones are barely usable? What do you really know? Which ones do you need to master but only barely use?
Thinking through these questions helps us keep a clear head about where we are right now and where we want to go in the long run.
Accumulate knowledge and not just experience
One of the characteristics of novices or beginners is that they tend to rely more on experience than knowledge, for example. For example, one of the most common problems encountered by novice backends is maven package failure. Many people resolve conflicts by MVN clean & MVN install. That is, empty and rebuild, because in most cases this command will solve the problem. So many novices memorize this command and repeat it every time maven fails.
What if this command doesn’t work? These guys might try a different order. What if all the usual problem-solving commands are tried and still don’t work? These people might freeze and decide that the problem can’t be solved and they have to call in the bull.
The core problem here is that novices accumulate experience rather than knowledge. They simply and mechanically map problems and solutions, rather than understand the reasons for problems and solutions to take effect from the principle and core level. The result is that the accumulated experience, the next problem can be solved not by learning the solution to the problem, nor by understanding this piece of technical content, but simply remember it. This, too, is clearly a pseudo-growth.
In fact, I have encountered this problem before, although I always consciously write down the solution to the problem so that I don’t have to ask others next time. However, although I recorded more and more problems, EVERY time I encountered a new problem, I still could not solve it, so I needed to consult others. It was not until one day that the bull I asked showed an impatient look that I made up my mind to learn to solve the problem by myself.
Therefore, I no longer tried to solve the problem in a stopgap way, but learned the principle and mechanism behind the problem, analyzed the cause of the error from the error log, thought about the solution, and finally learned the method to solve this kind of problem thoroughly. After that, I can not only solve problems by myself, but also help others. Looking back, I think I would have done better to try to learn the mechanics of the problem the first time I encountered it, rather than just memorize the solution.
Less talk, more code
Linus, the famous father of Linux, famously said: talk is cheap show me the code. Cut the crap and bring me the code. I think it’s very much in line with the spirit of the industry, that we don’t live by words, we live by actual output, and that output is ultimately translated into code. As a new person, maybe we will have such questions, such confusion. However, many of these problems and puzzles can only be solved with hard power.
Tan Haoqiang, the famous author of C language, also has a famous saying: “The best thing for beginners to learn programming is to write 10,000 lines of code that can work, and then you will naturally get started.” In fact, the truth is the same, less nonsense, more practical work. Do more practice, strength will not be poor. You can’t make a great man by dreaming about making a great man. So if you’re on the fence about learning a new field, but don’t know where to start, think about this: Forget it. Start coding first. As you play with it, you’ll know what to do next.
The above are some thoughts and ideas accumulated by myself. If you are a little white, I hope it can help you pass the rookie period smoothly and move towards the goal of great bull.
I sincerely wish you all a fruitful day. If you still like today’s content, please join us in a three-way support.
Original link, ask a concern
This article is formatted using MDNICE
– END –