What do young programmers need to learn most? self-discipline!

Over the past seven and a half years, I have mentored a dozen programmer interns at Ronimo Games and reviewed hundreds of resumes. I find that most of them need to learn one thing. You might think of it as some kind of technology, algorithm, mathematics, or some other form of knowledge. Of course, they do need to make up for this knowledge, but in my opinion, these are not the most important. The most important thing they need to learn is self-discipline. This self-discipline manifests itself in: writing code that is as clear as possible; refactoring code to eliminate confusion caused by changes in subsequent development; removing code that is never used and adding comments.

Most of the time I mentor interns is not in explaining high-level technical or engine details, but in getting them to write better code. I always ask internship applicants: What do you think is important to be a good programmer? Their answer is usually: the code should be clear, easy to understand, and easy to maintain. This is certainly what I want to hear, but few young programmers practice it consistently.

Doing this requires self-discipline, because it means that the code cannot stop at "implementing the function". Assuming that all variables are named arbitrarily, the code will still run perfectly, but will be less readable. In the short term, the payoff from "functional code" to "clean code" is small: the code works as it is, and the code still works after cleaning it up. This is why self-discipline is needed to complete this step, and this is why taking an internship can be helpful: a good mentor will pay enough attention to the quality of the code (although different people have different definitions of "good code") to ask for an internship Students will further improve and improve and move to the next stage.

Here are a few examples of problems I often see in code written by novice programmers:

Functions that don’t live up to their name/Variables/ Classes

These functions, variables, classes do not do what their names imply, and these names are deceptive. Obviously names should reflect what's really going on, but it's surprising to me how often they don't.

For example, I recently came across two classes written by a former intern: EditorGUI and EditorObjectCreatorGUI. This codebook is used to handle the interface in the editor. To my surprise, the code for the button to create a new object is placed in EditorGUI, while EditorObjectCreatorGUI handles operations between different objects, which is exactly the opposite of what the name implies! Although the code is relatively simple, it took me a while to figure it out because I made completely wrong assumptions based on the class name. The solution to this case is simple: rename them to EditorObjectCreatorGUI and EditorObjectNavigationGUI. Just doing a small step can greatly improve readability.

I have seen a lot of inaccurate naming. It happens frequently because code is constantly evolving. That name may have been correct when you initially chose it, but once the code is complete, the name may have become inaccurate or even wrong. This trap reminds us that we should always keep naming in mind. When you add a piece of code, you need to figure out whether it matches the name of the function or class.

Obfuscated Classes

Another problem is obfuscated classes, where a class does a lot of unrelated things. This problem can occur when you focus on the same block of code for a long time. New functions are implemented in the simplest way, and to a certain extent, the class becomes bloated and does a lot of irrelevant things. Sometimes classes become bloated not because of the size of the code: a class may only have a few hundred lines, but it contains code that is not part of the functionality of the class.

For example, if a GUI class needs to "analyze which textures are available" (imagine there is a button for selecting textures), if the GUI class is the only class that needs the results of this analysis, then implement it in the GUI class It's very reasonable. However, at this time a completely unrelated gameplay class also needs this analysis result information, so you pass the GUI class to the gameplay class to query the texture information. At this time, there is one more thing in the GUI class: it is a GUI class and also a TextureAnalyser class. The solution to this case is simple: separate a separate class from the TextureAnalyser class. This class can be used by both the GUI class and the gameplay class.

The best way to avoid this problem is to think twice before writing code every time: Does the function I add here match the name of the class? If it does not match, then the class must be renamed, or split into independent classes, or this code must be placed in other classes.

If you can’t think of a name that closely matches the class, this is usually a code smell (Bad Smell). If you can't find the right name to describe this class, it's probably because what it does is too confusing. At this point it can be divided into several parts and each part described with an appropriate name.

Bulky classes

This problem is very similar to the obfuscated classes mentioned above: as time goes by, more and more code is added to a class, making it become Got bloated. In this case, although it is reasonable to put it in a class, the size of the class becomes very large. It is very troublesome to deal with very large classes. When a lot of code operates on the same private member variable, bugs are easy to appear, and it is easy for people to overlook many details.

Splitting a very large class is quite boring work. This is also very challenging when the code is highly interleaved. Separating code requires a high degree of self-discipline, because it is just adding or modifying existing code while keeping the original functionality unchanged.

Ronimo Company has a rule to keep class code under 500 lines and function code under 50 lines. Sometimes this is not feasible or reasonable, but generally, no matter which class or function exceeds this specification, we will find a way to refactor or split it into smaller, more manageable pieces. (This makes me curious: How many lines do you think this limit should be? You can leave a message in the comments.)

Code Comments

Almost all the sample codes sent to us by internship applicants have some Commented code block, but does not explain why this comment is made. Is there an error in the code that needs to be modified? Or is the code too old and needs to be updated? Why is the commented out code here? When we asked the applicants, they also seemed confused about the commented code, but strangely, there was always some commented code for unknown reasons.

Code Duplication

Another problem I often see is the duplication of code with similar functionality.

For example, the purpose of this thing can be seen from the texture name, such as TreeBackground.dds. To know if this texture can be used for a tree, we check for file names starting with Tree. Maybe we can find it quickly after using the SDK, just use beginsWith("Tree"). This code is very short, if you need to use it, just paste it there. This is code duplication, and everyone knows that code duplication should be avoided. If the repeated code is short, the most attractive approach is to just copy and paste. The problem here is obvious: if we later want to check whether this texture applies to something else, we have to make corrections in a scattershot way, one place at a time.

Usually a better approach is that if the code has a special function, don’t copy it, but put it into a function. Although the code is short and short, and calling a function requires writing more code than pasting, you have to learn to do it, which also requires a high degree of self-discipline.

The topics discussed in this article are very simple and most people have already learned them during their first year of college. The hard part is going from knowing these things to actually taking the time to follow them to committing them to memory. That's why the most important thing everyone who has interned at Ronimo learned is not knowledge, but self-discipline.

Receive LAMP Brothers original PHP video tutorial CD/"Essential PHP in Detail" for free. For details, please contact the official website customer service:

http://www.lampbrother.net

http:// yun.itxdl.cn/online/cto/index.php?u=5 This, is a great X course CTO course

http://yun.itxdl.cn/online/server/index.php?u=5 Mobile Internet Server Side Development Course

http://yun.itxdl.cn/online/weixin/index.php?u=5 WeChat Development Course

http://yun.itxdl.cn/online/yingxiao /index.php?u=5Micro Marketing Course

http://yun.itxdl.cn/online/phpcms/index.php?u=5phpcmsSecondary Development Course