This week, bloggers read Chapters 11 to 13 of "Code Encyclopedia 2", the third part - "variables" is over, and the author of the fourth part will turn to the discussion of statements.
The authors of Chapter 11 elaborate on valid naming conventions for variable names, and Chapters 12 and 13 briefly describe the precautions for using various data types. In this blog, I will mainly talk about my reading experience on the naming of variables and the use of global variables.
The power of variable names
Let's talk about the need for naming conventions first. Why have naming conventions? Will it destroy creativity and procedural quality? This is what I mentioned in my last reading notes using the recent example of pair programming. Substantial constraints on program quality often come from high-level design, and effective standards can actually improve program quality and efficiency. Specifically, naming conventions have the following advantages:
1. Enhance the self-explanatory of the program, so that we can quickly read the code and recall our own thinking when we look at the program we wrote after a period of time; in teamwork, when the developer needs to take over the modification And when it comes to maintaining code written by other people, you don't get confused. This has important guiding significance for our next team project.
2. Playing by the rules allows us to focus on other areas that need to be fully considered (such as algorithms, class design, etc.).
3. Make the relationship between correlated variables clearer. For example employeeIDNumber, employeeAddress, employeeSalary obviously look more closely related than IDNumber, address and salary. Note that if we define an employee class in a programming language that supports classes and set IDNumber, address and salary as accessible data members, we can use employee.IDNumber, employee.address, employee.salary in external calls to express. From this we can see that good naming rules can also make up for the deficiencies of programming languages.
Since I started consciously naming variables in a way that suits my own reading and understanding, I often hesitated for a long time about the names of some intermediate variables. A good variable name should be readable, easy to remember, and appropriate. A variable description is the best variable name, but it is too long to be practical; short variable names are suitable for variables with small scope, such as ordinary loop counters. I have selected some suggestions from the book that I find more helpful to share:
1. Calculation qualifiers such as total, sum, min, max, average, pointer, etc. are placed in the front or back, and consistency can reduce the chance of making mistakes.
2. Use more counter words, such as the most common min/max, begin/end, next/previous, last/current, etc. These counter words should be placed in the front part or the back part of the compound word, and there should be a unified convention.
3. There are differences in naming methods for loop variables, state variables, temporary variables, Boolean variables, and enumeration variables. Do not use temp to represent temporary variables, add exact information after temp slightly, or give away temp to give a more accurate description. Do not use status for boolean variables, because no matter whether it returns true or false, it does not have any specific meaning to the current process. Using isDone, isError, success will make the meaning of the variable more precise.
4. Named constants can be described as detailed as possible with a combination of capitals and underscores.
5. Sometimes due to the limitation of the length of variable names in programming languages, we have to use short names, and abbreviations also involve a lot of skills, basically to serve readability, such as using the abbreviations listed in the dictionary, removing Some non-front vowels, such as source becomes src, computer becomes cmptr, of course, it is not necessary to remove all vowels. For example, xPosition is abbreviated as xPos, which is easier to understand than xPst.
There is also a subsection in the book on informal naming conventions for short, throwaway programs. I personally don't think it is necessary to understand, because we need to cultivate good naming habits in daily programming practice and explore efficient naming rules to ensure the quality of variable names in actual combat.
Use global variables sparingly
全局变量的风险是程序员的常识，然而在实际编程过程中我们往往还是会和全局比变量打交道。编写汇编程序的时候，定义在代码段的变量都是全局变量，又比如我使用Keil为单片机芯片编写程序时，涉及到中断操作时也常常会用到全局变量。然而在用面向程序和面向对象语言编程时，使用全局变量还是谨慎一些。我们来看看全局变量有哪些缺陷：
1.违反了模块化和信息隐藏的原则，增大了所需管理的复杂度。如果一个子程序和用到了全局变量，那么在编写、调试这个子程序的时候还得同时考虑到这个全局变量而不仅仅是这个子程序本身。
2.全局数据会阻碍代码重用。想象一下你需要使用在另一个文件中定义的类或子程序，而这个类或子程序又使用了定义在那个文件的全局变量，那么是否需要在当前文件中重复定义这个全局变量？定义之后能保证这个变量的值按照你所期待的维持或变化吗？
3.多线程编程中的代码重入问题：多线程代码运行过程中有可能全局数据在同一个程序的不同拷贝之间共享，这种情况下必须确保全局变量还保持有确切的含义。
全局变量一般适用于一些在概念上用于整个工程的数据以及在程序的每一个子程序中都需要用到的数据或变量，编程语言不支持具名常量时也可以用全局变量来模拟，不过往往这些目标都可以通过其他更好地方式来达成。如果迫不得已一定要使用全局变量，可以尝试用以下方法来降低风险：
1.为全局变量选取一个与其他变量不同的、更醒目的命名方式。
2.列出全局变量的清单，标注具体功能，在调用全局变量的地方适当注释作为提示。
3.不要用全局变量来存放中间结果。