5 lessons young programmers need to learn

In the past 7, I have led more than a dozen software interns and have seen the profiles of hundreds of students and graduates. I find there are a lot of things they need to learn. Maybe you will say, aren’t I talking about a specific technology, algorithm, mathematics, or other specific form of knowledge? Yes, this is something to learn, but it is not the most important thing. The most important thing they need to learn is "self-regulation." These norms are: write the simplest code possible; if the code will become messy due to changes later, refactor it; try to delete useless code and add comments.

I spent a lot of time urging these interns to learn these contents. I often ask them how to become a good PHP programmer, and they usually answer that the code should be clear, easy to understand and easy to maintain. This is indeed what I want to hear, but few young programmers can actually implement this consistently.

Please keep this in mind, you must understand "self-regulation", and you cannot immediately forget about the code once it "works". If all the variables are named incorrectly, but the code still runs perfectly, the code will be an unbearable mess. Improving functional code to concise code may not pay off in the short term: the code that worked originally will still work after cleaning. This is why you need the “self-regulation” step. This is why internships are so necessary: ​​a good boss is very focused on code quality (even if the definition of "good code" is different for every programmer), thus forcing interns and junior programmers to have to revise it over and over again. .

Some of the examples I gave below are often seen by novice programmers when they write code:

Function/variable/class that does not deserve the name

These functions and classes What the variable actually does is inconsistent with what its name indicates. It is correct to look at the names one-sidedly, but when it comes to reality, some of them are even irrelevant.

For example, my last intern wrote two classes: EditorGUI and EditorObjectCreatorGUI. Code for handling the editing interface. What makes me dumbfounded is that the one used to create new objects is the EditorGUI, while the EditorObjectCreatorGUI can only navigate by handling different objects. The meanings of the two are actually completely opposite! Even though the code is relatively simple, it took me quite a while to understand it because I started with the opposite assumption. The solution to this situation is very simple: just rename EditorObjectCreatorGUI to EditorObjectNavigationGUI, which will be much easier to understand.

I have seen this happen a lot. This happens because the code evolves during the work. The name may be correct when you choose it, but by the time you finish writing the code, it may not be worthy of the name. The key is to always keep naming conventions in mind. You have to understand whether what you add still matches the function and class names.

Confused classes

Another problem is that classes are confusing: they do a lot of unrelated things. Adding new features is easy, but slowly, you will find that your code becomes bloated, and various irrelevant features can be seen everywhere. Sometimes, bloat doesn't refer to the size of the class: a class may only have a few hundred lines, but still include code that doesn't belong in it.

Why does this happen? For example: suppose that for some reason a GUI class needs to analyze what textures are available (perhaps there is a button to select a texture). If this GUI class is the only class that needs the results of this analysis, then it makes sense to do this in the GUI class. However, for some reason, a completely unrelated gameplay class also needs this information. So you need to pass these texture query information from the GUI class to the gameplay class. At this time, the GUI class has actually become larger: because it actually includes the TextureAnalyser class. The solution is also simple: split the TextureAnalyser class into a separate class, which can be used by both GUI and gameplay classes.

Many people have questioned this rule of thumb: What if the functionality I add still fits the name of the original class? If it doesn't fit, do I have to rename it, split it into a separate class, or code it into a different class?

If you can’t come up with a suitable name for your class, it will make people feel uncomfortable. If you can't describe the purpose of a class in its name, it will look cluttered. Sometimes we also need to split a bloated class into several parts and give each an appropriate name.

Overly large classes

This is similar to the previous point - confusing classes: a lot of things are added to the class bit by bit, and then it inevitably becomes bloated . In this case, such a class still makes sense, but it just gets a little too big. Such a behemoth is not only cumbersome, but also prone to bugs. Because a large amount of code needs to be used to operate the same private member variable, it is easy for us to overlook some details.

Splitting a class that has grown too big is actually quite boring. This can also become a challenge if the code in the class is highly intertwined. Coupled with the fact that it is already working and no new features can be added while it is being fixed, I have to say that splitting up a class that is too large and cannot strictly regulate itself is not an option.

According to the general experience in Ronimo, it is most appropriate to keep classes under 500 lines of code and functions under 50 lines of code. Sometimes, though, this isn't feasible or wise. But generally speaking, once a class or function exceeds that boundary we can find ways to refactor and split it into smaller and more manageable pieces.

About code comments

Almost all sample code will contain commented code snippets without explaining why. Does this code need fixing? Has the old code been replaced? Why is this code written there? Everyone knows that code without comments often means nothing, but for some reason, many people forget to comment on their code.

Parallel logic and code duplication

Another problem is that I often see similar logic in several code segments.

For example, we can know its approximate target object from the name of the texture, such as "TreeBackground.dds". To know if the texture can be used with a tree, we check the filename to see if it starts with "tree". If you may use the SDK, we can quickly detect it using filename.beginsWith("tree"). It’s just that this code is so short, we often choose where it is needed and just copy and paste it directly. Of course this is code duplication, and as everyone knows, we should avoid duplicating code, but if the copied code is so short, we tend to forget this and naturally copy it directly. The problem we face here is also obvious: maybe our method of checking whether a texture is suitable for the tree will have to change later, and then we will have to implement a "shotgun modification" (that is, modify it everywhere) strategy, one place at a time. Ground repair.

The general rule here is that if it is very specific code, do not copy it. Even if the original code is super short and calling a function requires more code than writing it directly, it should be encapsulated into a function. .

The contents discussed above have been explained very thoroughly. A lot of it you even learned in college. But the challenge now is that you need to develop a habit step by step from passive compliance to active remembrance. This is why the most important thing for interns in Ronimo is not to learn knowledge, but to learn self-regulation.

Get Brothers IT Education original PHP tutorial CD/"Essential PHP in Detail" for free. For details, please contact the official website customer service: http://www.lampbrother.net

Learn PHP, Linux, HTML5, UI, Android, etc. Video tutorial (courseware + notes + video)! Contact Q2430675018

Participate in the event to receive the original video tutorial CD collection of Brothers: http://www.lampbrother.net/newcd.html