如何让命名变得优雅

1.概述

　　在写这篇文章时，我也是酝酿了许久；在平时编码时，也经常苦于如何命名让变量，函数及类变都优雅，美观。因为，有时候看回过头来看代码发现，一个变量或是函数名特别是有单词组合都时候，会觉得有些单词组合在一起，看起来很别扭。举个例子，如类型统计：typeStats，statsType，categoryStats，statsCategory。其中2看的最别扭，3其次，1和4都还可以接受。当然这个也不是说2，3不行，这里我只是想说明命名之前，我尽可能的多组合自己的变量，使最后的命名更加优雅。

2.心得

　　这里总结一下自己在平时多使用心得，故总结以下心得：

　　2.1不同多代码段采用不同段命名长度

类型	长度
循环变量	1
方法	1-2
类	2-3
全局变量	3-4

 

　　2.2对变量采用具体对命名方式

　　“value”，“equals”，“data”在任何情况下都不是一种有效对命名方式。

　　2.3采用有意义对命名

　　变量的名字必须能够准确反应它的含义和内容。

　　2.4变量不需要前缀标签来表示自己使一个变量

　　如：　n_，obj_，_p

　　2.5遵循公司的变量命名规则，在项目中坚持使用同一种变量命名方式

　　如：txtUserName，lblUserName，cmbIsAdmin等，否则会对可读性造成影响，而且会令查找/替换工具（find/replace tools）不可用。

　　2.6遵循当前语言对变量命名规则

　　在命名使，要和当前的命名规则匹配，不要另起规则。常见的问题：userName,username,UserName,USER_NAME等。

以Java的规则为例：

• 类名使用驼峰命名法：AppDedail
• 包名使用小写：cn.company.utils（cn.company.业务名）
• 变量使用首字母小写的驼峰命名法：appInfo
• 常量使用全大写：MAX_SIZE
• 枚举类采用驼峰命名法，枚举值采用全大写：Configure，APP，APP_NAME
• 除了常量和枚举值以外，不要使用下划线：“_”

　　2.7在同一个类不同的场景中不要复用变量名

　　

public class App{
      public App(String appName){
            String name = appName;
            // ....... 省略后面的代码 ......  
      }  
      
      public void show(AppDetail app){
            String name = app.getAppName();// 构造方法中已使用name变量
            String appName = app.getAppName();
      }
}

　　如：在方法，初始化方法和类中，这样做可以提高可读性和可维护性。

　　2.8不要对不同使用目的对变量使用同一变量名

　　同2.7一样，赋予它们不同的名字，这样对保持可读性和可维护性很重要。

　　2.9变量名不要使用非ASCII字符

　　这样做的后果会导致在跨平台使用时产生问题。

　　2.10不要使用过长的变量名

　　变量名不要超过50字符，过长的变量名会导致代码丑陋和难以阅读，还可能因为字符限制在某些编译器上存在兼容性问题。

　　2.11仅使用一种自然语言来命名

　　例如：在同时使用英语和日文来命名会导致理解不一致和降低代码的可读性。

　　2.12使用有意义的方法名

　　方法名必须准确表达该方法的行为，在多数情况下以动词开头，如：createPassword。

　　2.13遵循公司的方法命名规则

　　在项目注坚持使用同一种方法命名方式，如：getTxtUserName(),isAdmin(),updateUserInfo()，否则会对可读性造成影响，而且会令查找/替换工具不可用。

　　2.14遵循当前语言的变量命名规则

　　在命名时，不要不统一的使用大小写字母，如：

　　以Java为例：

• 方法使用首字母大小写的驼峰命名法：getStudentInfo
• 方法参数使用首字母大小写的驼峰命名法：insertStudentInfo(Student stu)

　　2.15使用有意义的方法参数命名

　　这样做可以在没有文档的情况下尽量做到“见明知意”。

3.总结

　　细节很重要，平时编码时需要注意的一些细节，时刻记住，我们编码是为了让别人更好的去阅读你的代码，而不是“迷惑”别人。一次在阅读代码时发现以前一哥们写的注释，我瞬间内心暖暖的。大概内容如下：

private int getSummary(Manager manager){
       //  为了BT的需求，破坏了代码优雅的结构(￣▽￣)
}

　　最后说一句，同是程序员，程序员何苦为难程序员！！！