Author | Amu
Zebian | Wu Xingling
Produced | Life program (ID: coder_life)
In addition to his own people did not write the code can understand, is a kind of experience?
Below digging by me as a senior programmer, taught everyone how this is done? If you can practice more next time, the so-called better players, I am sure you can write code that others can not only maintain, but also may one day even be able to write their own code consummate skills are not maintained.
Unable to write maintainable code that is difficult is not difficult, coding standards and core point is the opposite, if we add some out on her own experiences on this basis, then it would be more perfect.
The point is not enough mastered, but also pay attention to one principle: Do not let our code will not be able to maintain glance , like the format still have to pay attention to, and can not be maintained on we want to pursue this is not the superficial surface, What we want is the essence can not be maintained.
If someone else be able to see your code can not be maintained, and that there is a risk that your code needs to be rewritten or reconstruction, and it does not become undone loved ones pain, hatred, quick thing thing.
Clear understanding of conventional programming way of thinking re-start!
"Art of War" goes "Know thyself, know yourself", if we want to completely defeat the follow-up code from the psychological maintenance personnel, we have to understand the way of thinking of some conventional programming.
First think, if it took over the program of our own, and the code than the larger, generally we do not have the time to read it from start to finish line by line, not to say that can understand code.
In order to be able to cross the line on the ground as soon as possible, a common practice is based on the needs of programmers, to quickly find the logic that part of the code needs to be changed, then modify the code part of this test. Such modifications can only see a small portion of code, piece of a jigsaw.
So we have to do is to ensure that code maintenance personnel can not always see the whole picture we write the code, the code to try to ensure that maintenance personnel can not find that part of the code he wants to find it. This is not the most critical, the most critical is to make modifications knows he did not ignore any of the stuff.
Each of our well-designed trap these small codes will force defenders like with a magnifying glass-like, we carefully read every line of code.
Some students may think that this is very simple, as long as in accordance with the principles mentioned above can be counter-programming specifications. But in practice it is not so simple, but also with our carefully before misuse. Here we could go on for some common core skills.
Python: reduce by half the memory footprint line of code!
The first one: in all seriousness indiscriminate use of annotations
In this section we first understand the normal use under annotation: annotation is used to help developers understand the program, especially for the later developers can quickly understand the actual role of the code with comments.
The principle of code comments under normal circumstances usually only comments where necessary comment. This is a very correct nonsense, it is a very clear explanation of the code is not going to be able to read the comment, after all, to see the comments also takes time.
Another principle is stated in code comments action required and the actual role of the code is the same.
In practice, together with the comments of the code must also be modified with the following modifications to your code. Other comments about our role here say no more, we just had enough with those of the.
How to use the code to write code comments people can not understand it?
First, the entire multi-useless
I divided piece described two cases, two cases corresponding to the two treatments, strong practicability.
-
Clear style comments
Let defenders waste time watching the obvious comments.
This principle is part of defenders after reading the comment that "the code easier to read than more comments", the purpose is to mislead people read the code. Defenders when looking at the code, touched upon a very clear look at the code, but there could be another look at the comment .
At this time, read the code of the human heart is certainly to be muttering under: It seems that the code is not as simple as I thought.
Then we write longer comments, and finally to the reader can not read, the time change of indecision.
If you can afford it, then you can teach defenders how programming in comments , write this general destruction will be higher than the above, the programmer is probably the most disgusting you have to teach him how programming, especially to teach him so simple programming, lethal doubled.
The following look at an example:
-
Abandoned code comments
Literal meaning is very clear that, under normal circumstances, the code will generally not part of our immediate comment out or deleted, even though the code will not affect the use of the future, you can get it back from the version control tool.
Targeted approach is to add the code to delete the long comment stating why this code is commented it also sends a message to the defenders, that this code is not "abandoned", but "temporary" first do.
To do so in the killing point, look at the code if the code is not only the Notes plus explanatory notes, based on actual experience most people will ignore it be annotated code, and added a note to the code might have to look at this comment , or else what key information is missing, after all, the code is not written by him.
Boilerplate code:
Second, this place could be modified in the future
This type of comment is the "TODO" comment type we often mention. Under normal circumstances TODO comment is not without merit, such as when the project initialization TODO comment is very useful, when the project release is generally recommended to remove if necessary to keep the general need to be stated in what specific date will be disposed of. Is generally not recommended TODO annotation type persist in the code of the project, the normal processing logic generally have to follow Bug Fix as soon as possible, then Bug removed without comment.
Through the above description, I believe we already know how to deal with a piece of concrete. Personal recommendation is to be revised and more reason to write TODO comment, and does not indicate the change and the time change of plan, so the following maintenance personnel when looking at this in the end is not likely to even have to turn over are confused, so, there are also killing effects of.
Boilerplate code:
Third, the error message comments
This means that part of the cause does not match the code and comments, annotation information is incorrect.
We have to do is finish the code after the change does not change the comment on the line , this way relatively easy, do not do a little extra work, but the price slightly, to note that the best is to add a special in such comments mark, to prevent their own follow-up time to look around themselves inside.
Examples of this model would not increase it, the scene too much, you can improvise when you farming in their own third of an acre on the ground.
Fourth, storytelling
It simply is stated why write code, of course, is certainly not a simple reason. In addition to the reasons generally recommended to write in a comment on the situation, such as a certain period and someone addressed this issue in a certain place, somebody says how this should be dealt with, you said the issue should not be treated as such treatment, later he joined the discussion so and so, so and so to discuss both made certain rating, and finally decided to use the current code to achieve this functionality.
In short, the principle is to clearly describe the details of the matter, the more detailed the better. Some students may suggest to the day's weather also write , there are discussions that the stakes of S * name but also bring, I personally think that the weather can be added as appropriate, but the name is written on S * is not encouraged, after all, a colleague, to care for each other, all in accordance with the actual situation of their own company to select a specific approach it.
Boilerplate code:
Fifth, do not write the reason
Accordance with the norms of the comment, when the comment not only interpreter of the meaning of the expression, more importantly, how to write stated that what the reason code written so yes.
Such countermeasures have been obvious, for complex procedures, such as some special boundary conditions to determine, write down only the literal meaning of the program, the specific boundary value to determine why write, why is this value can be ignored, so that people maintained enjoy guess it.
Sixth, trivial
In this program needs to be indicated that the majority of comments are generally less than this, is generally recommended on to explain some complex algorithms, the more complex algorithms more recommendation, the principle is this part should be written the contents of the document written code.
All of the detailed design must take algorithms are written on, sub-paragraph annotation content to be graded between paragraphs, each suggested adding numbers, so you can basically ensure that the content code comments and documentation consistent. Ongoing maintenance see such comments when the basic guarantees big head around, if there is a better, then the effect of such comments of many.
In view of the comments space model example illustrates the increase is not too long.
Seven, the unit problems
This part of the unit and the specific business-related scenarios, such as the time generally have associated milliseconds, seconds, minutes, hours, days, months, years, etc., related to the size of the pixel scene, inches, etc., file size is a byte, such as the scene , KB, MB, GB and so on.
This type of code, our principle is not to annotate units, just use, if you can mix various units in the code , it is naturally more outstanding.
For example, in the scene on file processed, KB, MB, GB multiple units of mixed use, so subsequent maintenance staff in order to get to know the true meaning of the code in this unit will be done on a part.
According to our normal logic, the logic behind who wants to change this part of the code of each data unit First you have to understand, is certainly not free to modify the previously clear, the general case is only one solution and that is over and over again to debug, test program to calculate the actual data of each unit is naturally quite much time it takes.
Eight, intimidation
This move can be said to be the killer-level annotations, you can add optional part of the code in the program, and that is obviously dispensable , then add a comment to this program, the comment states that " Do not delete or comment out this code, otherwise the program will be abnormal !!! ", need to pay attention not explain what kind of abnormality occurs.
So maintenance personnel at the time certainly see this code will first think of some of the articles themselves seen before, and firmly believe that this "nonsense Code" certainly can not be deleted. If this code multiple comments exist better.
Cover-up articles
I. Getting Started
Let your code and notes blend together, be regarded as entry-level code steganography, the main purpose is disgusting later defenders, people just look at the code if dizzy, then certainly a direct rip off force will, after completion of senseless force and then a wave of nausea.
If the logic code is exactly the same strain and comments that down naturally better, specific operations may reference samples following examples.
Model Example:
Second, synonyms
Such moves are generally recommended for use in macros class C program, principles for the use of relatively simple, that is, the macro name and the specific value of hybridity can use, create a you have me, I have you both view sense.
Model Example:
Third, naming inconsistencies
This part is mainly used in front-end development, for example everyone is clear, such as zip code displayed on the Web interface for the postal code, the code name of the variable named zipcode, I believe that no matter who see this are not directly change the code, it must be repeated to confirm a postal code corresponding to the variable in the end is not zipcode.
Fourth, the macro definition hidden
It should be noted here is not to say that the hidden macro definition can not find places to hide, it certainly does not work, maybe we ourselves have to modify it.
Here that means not hiding macro definition macro definition will be written in the macro definition, let's look at the code at a glance who think this is not a macro, and then a little past.
Man of few words said on the model:
Fifth, wrap the variable name
I use this trick can only be described as insignificant, because it is really insignificant. The effect is that is difficult to read too difficult to search for a variable name.
Model Example:
Sixth, global variables
Here that is hidden global variables, the method is not used directly in the function when using global variables inside, but used after passed in the form of parameter passing, so that it is difficult to distinguish a global variable.
Seven, function overloading
After the normal function overloading, which features and functions should be overloaded should be close, we have to do is let the performance function overloading and function overloading is nothing to do .
This time, if people look at the code base is not strong, it may need to brush up on knowledge function overloading, is not his past wrong.
Eight, operator overloading
Operator overloading is a very abnormal moves, because he will make your code becomes very strange, as long as the manner described below using a basic code clutter can be pulled directly to the level of art, and art is to break the routine , as long as it is generally not in accordance with the recommended use of operator overloading way to use you can receive unexpected results.
Example model:! Class overloaded operators, the reload function but is not allowed to take returns an integer, so when using !! will first call the function is overloaded, returns an integer, then negated, Finally, return a bool value, and a look ignorant force.
Nine, confusion #define
I think after this trick to spend the people looking at the code if it is not as solid as the old dog old driver should be the cry. I do not believe this can be seen below boilerplate code.
Model Example:
Variable Command articles
First, any capitalization alternately
这种基本上就是一种骂娘的命名方式，为啥会这么容易引起怒火，看个例子就知道了：gGEtpRoDucTnaME，有没有脑裂的感觉？
二、单字母变量
名称上毫无逻辑可言。
样板代码：
三、字母+数字很配
如果字母a – z 不够使用，可以考虑字母+数字的组合，这样一般就足够使用了，毕竟数字是无限的。
样板示例：
四、故意拼错
变量名称拼错并不是随意一个单词就拼错，此处指的是比较有创意的拼写错误。
因为随意的拼写错误是很容易被发现的，高级的拼写错误由于很难看出来，所以在进行变量搜索的时候根本搜不出来。 比如：SetPintle、SetPintalClosing。
五、重复名称
函数或者方法的内嵌结构中使用和函数或者方法层面中同名的变量名，变量名多的话可能会一阵眩晕。
进阶篇
前面的注释和变量命名可以说是本文的基础篇，主要是较大家一些基本的编程技巧。这一篇作为进阶的一篇，我会给大家介绍一下常见的一些稍微高端的编程技巧，废话不多说，一起看下：
一、void*
不管什么类型的指针一律都用声明定义为void*，当实际用到时再转换为需要的类型。
二、条件表达式
条件表达式这块可以发挥的空间就比较大了，从实际编码情况来看，每个简单的条件表达式都可以进行拆分，看个例子就明白了。
10 == num，拆分为 num >= 99 && num <= 101
三、长代码
什么，一行最多80个字符？ 不行，这才哪到哪，一定要跨行，而且要跨多行，不能因为换行影响了我们写代码的那股激情。
原则就是越长越好，这样后续阅读代码的人就需要来来回回地读，想想都觉得累。
四、嵌套
一个优秀的程序员必须能够在一行代码中使用超过10个小括号()，如果觉得很难得话在一个函数里面使用超过5层的大括号也是可以的，还不行的话把嵌套的条件语句if … else 转为[?:] 也是可以说明你是个优秀的程序员的。
五、不要break
不要在代码的循环中使用break，更不要使用goto，这样可以保证一行break可以处理的代码最少要写5层的if … else 来解决，一遇到break 就多出百十行代码，想想都过瘾，一天下来光看看新增的代码行数就觉得充实。
六、尽量使用XML
XML 的强大是无人能及的，不是JSON、Yaml这些所能及的。项目中使用XML 可以帮助我们将原来只需要10行的代码变为100行(可能还不止)。XML是无所不能的，哪怕是自己封装自己也是可以做到的，信XML 得永生，信XML 的自信!
样板代码：
七、测试
测试，不存在的。
一般建议不要测试，测试是一种懦夫的行为，作为一个优秀的程序员我们必须保持这种对自己代码的自信，再者测试会影响你的生产力，直接影响你写代码的行数，所以测试这一步直接跳过就好啦。
作者简介：阿木，目前就职于国内某知名互联网公司，担任云计算技术部高级工程师，近3年云计算从业经验，爱读书、爱写作、爱技术。
热 文 推 荐
☞V神已抵京, 倒计时4天! 6大理由告诉你为什么要参加"2019以太坊技术及应用大会"
☞Flink最锋利的武器：Flink SQL入门和实战 | 附完整实现代码
Click to read the original text, enter keywords, search CSDN article.
Your point of each "look", I seriously as a favorite