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

In the past 7.5 years, I have supervised more than 10 programmer interns in Ronimo games and reviewed hundreds of resumes. I find that most of them need to learn one thing. You may think that this is a technique, 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. One of the most important things they want to learn is self-discipline. This self-discipline manifests itself in writing as clear code as possible, refactoring code to eliminate confusion caused by changes in subsequent developments, removing code that has never been used, and adding comments. I've been coaching interns for most of the time not on high-level technical or engine-specific explanations, but on getting them to write better code. I always ask the intern applicant: 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 can mindedness to practice. Doing this requires self-discipline, because it means that the code does not stay in "Implementing functionality." Assuming that all variables are randomly named, the code still works perfectly, but the reading is poor. In the short term, there is little return from "Functional code" to "Clear Code": The code is ready to run and the code can still run after it is cleaned up. That's why self-discipline is needed to do this, and that's why it's helpful to take an internship: A good mentor will pay great attention to the quality of the code (although different people have different definitions of "good code"), thus requiring interns to further refine and move on to the next stage. Here are a few examples of the problems I often see in the code written by the novice programmer:a function of a misnomer/variable/classWhat these functions, variables, and classes do is not what their name implies, and the names are deceptive. Obviously the name should reflect the real content, but to my surprise, this is often the case with a misnomer. For example, I recently stumbled across two classes written by a former intern: Editorgui and Editorobjectcreatorgui, the code used to handle the interface in the editor. To my surprise, the code for the button that created the new object was placed inside the Editorgui, while Editorobjectcreatorgui was dealing with the operation between the different objects, which was the exact opposite of what the name implies! Although the code is relatively simple, it took me a while to figure it out because I made a completely wrong assumption based on the class name. The solution to this case is simple: Rename to Editorobjectcreatorgui and Editorobjectnavigationgui, just one small step can greatly improve the reading. Naming is inaccurate I see a lot of this situation. The reason why it happens so often is that the code is constantly evolving. It may be correct to initially select that name, but once the code is complete, the naming may become inaccurate or even wrong. This trap reminds us that we should always keep the name in mind and make it clear when you add a piece of code that is commensurate with the name of the function or class.Confusing ClassesAnother problem is confusing classes, where a class does a lot of unrelated things. This can be a problem when you focus on the same piece of code for a long time. New features are implemented in the simplest way, and at some point the classes become bloated and do a lot of unrelated things. Sometimes the class becomes bloated not by the size of the code: A class may have only hundreds of rows, but it contains code that is not part of this class of functionality. For example, if a GUI class needs to "analyze which textures are available" (Imagine a button to select a texture), it is reasonable to implement it in a GUI class if the GUI class is the only class that needs the result of this analysis. However, a completely unrelated gameplay class also needs information about the results of this analysis, so you pass the GUI class to the gameplay class to query the texture information. This time the GUI class has one more thing: It is a GUI class, and also a Textureanalyser class. The solution to this case is simple: separate classes from the Textureanalyser class, which can be used by both the GUI class and the gameplay class. The best way to avoid this problem is to think twice before you write the code: Does the feature I add here match the name of the class? If not, then rename the class, or split it into a separate class, or put the code in another class. If you can't figure out a name that matches the class very well, this is usually a code odor (bad smell). If you can't find the right name to describe the class, it might be because things are too mixed up. It can then be divided into several parts, and each part is described with a proper name.Large-Volume classThe problem is similar to the confusing class above: over time, more and more code is added to a class, making it bloated. In this case, although it is reasonable to put in a class, the volume of the class becomes large. Super-large classes are cumbersome to handle, and when a lot of code operates on the same private member variable, the bug is easy to come up with, and it's easy to ignore a lot of detail. Splitting a super-large class is a pretty boring job. This can also be challenging when the code is highly interleaved. Separating the code requires a high degree of self-discipline, because it only adds or modifies the existing code to keep the original functionality intact. Ronimo Company has a rule, keep the code of the class below 500 lines, the code of the function is below 50 lines. Sometimes this is not feasible and unreasonable, but generally speaking, regardless of which class or function exceeds this rule, we will find a way to refactor or split it into smaller, more manageable fragments. (It makes me wonder: How many lines do you think this limit should be?) You can leave a comment in the comments. ）code CommentsInternship the applicant sent us the sample code almost all 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 to be updated? Why is the commented-out code here? When we asked the applicants, they were puzzled by the annotated code, but strangely enough, there were always some unexplained annotated code.Code DuplicationAnother problem I often see is that code that has similar functionality repeats itself. For example, from a texture name it may be possible to see the purpose of this thing, such as Treebackground.dds. To know whether this texture can be used in a tree, we check the file name that begins with the trees. Maybe we can find it soon after using the SDK, and using Beginswith ("Tree") is OK. This code is very short, if you need to use it, paste it directly there. This is code duplication, and everyone knows that code duplication should be avoided, and if the duplicated code is short, the most appealing approach is to copy and paste directly. The problem here is obvious: if you want to check if the texture is suitable for something else, we're going to have a shotgun fix, a place where one is fixed. It is usually good practice if the code is special, do not copy, but put it into a function. Although the code is short and short, and calling a function requires more code than pasting, you have to learn to do so, which also requires a high degree of discipline. The topic discussed in this article is very simple, and most people have learned it in their first year of college. It is difficult to learn from these things to actually take the time to follow them, and then to keep them in mind. This is why all the people who have been practicing in Ronimo have learned the most important thing is not knowledge, but self-discipline. Free to receive the lamp brother even original PHP video tutorial CD/"Detailed PHP" Essentials version, details of the website customer service: http://www.lampbrother.nethttp://yun.itxdl.cn/online/cto/index.php? U=5 This is a Bull 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 Development Course http://yun.itxdl.cn/online/yingxiao/index.php?u=5 Micro Marketing course http://yun.itxdl.cn/online/ PHPCMS/INDEX.PHP?U=5PHPCMS Two-time development course

