本文探讨了在软件开发过程中，良好的命名对于提高代码可读性和可维护性的重要性。介绍了如何进行有效的命名，并通过实例展示了混乱命名所带来的问题。
一个软件最后都会落实到代码，而代码，其背后的架构设计或设计思想或模式固然重要，但我觉得更重要的东西则是良好的命名。混乱或错误的命名不仅让我们对代码难以理解，更糟糕的是，会误导我们的思维，导致对代码的理解完全错误。相反，良好的命名，则可以让我们的代码非常容易读懂，也能向读者正确表达事物以及逻辑的本质，从而使得代码的可维护性就大大增强。
另外一点也许大家还没感受到，那就是良好的命名，以及良好的命名习惯，由于我们总是对每个概念的名称要求非常苛刻，我们会思考这个名称所表达的概念是否正确，该名称是否正确表达了事物的本质或正确反映了某个行为的逻辑。所以，这种对命名的良好思考习惯，可以反过来帮助我们纠正之前的一些错误设计和代码实现；比如，你之前有一个地方可能命名不太准确，然后你发现后面有另一个地方需要用这个名字，且更合理。所以你会发现这个名字对前面的地方就不适合了，从而你会去思考前面的地方可能需要用其他的名字，或者你会发现前面的地方的设计根本就是有问题的。这种就是名字可以促使你思考你的设计是否正确的例子。
我觉得导致混乱或错误的命名的原因主要是：
- 没理解事物的本质；
- 理解了事物的本质，但不知道命名的重要性或者根本不屑于做好命名；
- 理解了事物的本质，也知道命名的重要性，但没能力命名好事物；
所以，要养成良好的命名习惯，我总结了一些我的想法：
- 对自己的严格自律，自己写代码时要有一种希望把每个名称都命名好的强烈意识和严格的自律意识；
- 要努力分析和思考当前被你命名的事物或逻辑的本质，这点非常关键，思考不深入，就会导致最后对这个事物的命名错误，因为你还没想清楚被你命名的事物是个什么东西；
- 在有自律意识和一定的分析能力基础之上，注意命名的方法技巧；要知道何时用动词，何时用名词；以及形容词放哪里，动词放哪里，名词放哪里；也就是小学时的主谓宾要会用；
- 要让你的程序的每个相似的地方的命名风格总是一致的。不要一会儿大写，一会儿小写；一会儿全称一会儿简写；一会儿Pascal命名法，一会儿camel命名法或匈牙利命名法；
- 不要出现重复的命名；因为通常名称都有嵌套关系，比如类在命名空间里，方法在类里，所有如果一个概念在命名空间里表达了，那就不必再类上再表达一次；
- 对于属性或类名，应该总是名词在最后面，名词决定了这个属性代表什么，前面的部分都是用于修饰这个名词；比如，假如现在你有一个服务，然后又是一个关于订单的服务，那就可以命名为OrderService，这样命名就是告诉我们这是一个服务，然后是一个订单服务；再比如CancelOrderCommand，看到这个我们就知道这是一个Command，即命令，然后是什么命令呢？就是一个取消订单的命令，CancelOrder表示取消订单；
- 对于方法，应该总是动词开头，名词结尾；比如Order.AddItem(orderItem);这个，表示订单类有一个添加订单项的方法，Add是动词，表示添加，Item是名词表示订单项；
下面我们通过看一些命名的不太好的代码来知道我们命名时哪些细节需要注意：
以上代码中，有很多问题，我们来一一分析：
- 方法的参数，第一个字母，一会儿大写的P，一会儿小写的p，不一致；
- 第二个参数后面出现多余的空格，不应该；
- _paramsTable这个参数为什么要出现下划线，而其他参数没有下划线，不一致；
- publishRequest属于camel命名法，而iSignCounter, sStageIsOK这种属于另一种命名法，这种命名c++中用的多，不一致；
- foreach循环中，参数名叫instParam，但是后面的集合叫arrParams4SignActions，更对称一点的，应该叫arrInstParam；
- 方法的最后两行，出现多余的空格，导致代码格式排版混乱；
从上面的代码我们可以知道，仅仅是通过这些细节，就能发现很多问题。我们写代码时，只要多细心点，多注意点排版是否美观一致、命名是否统一，那代码写出来就会漂亮很多了。下面我们再看看其他的代码：
- 上面的代码中，两个参数的命名也不一致，projectid中，i是小写，但是publishId参数，i却是大写，应该都统一为大写；
- ViewData中的key，一会儿是全部大写的UPDATE，一会儿是另一种命名，不一致；
- 上面的两个红框标出来的if，虽然都是只有一行代码，但是一个有括号，一个没有括号，不一致；且第二个if里出现了多余的空行，格式混乱；
- 上面的代码中，函数中，一会儿用IList，是一个接口，一会儿用Dictionary，非接口，不一致；应该都用接口，或者都不用接口；
- listOriginal和receiverList命名不一致，要么全部list开头，要么全部List结尾；
- foreach循环中，变量的类型叫TDMSOriginalRequirement，但是变量名却叫originalItem，而集合名称又叫listOriginal，应该三者统一；比如foreach (Assembly assembly in assemblies)
- +“...”这个地方没有用空格，加号两边应该要空格，这属于格式混乱，不严谨；
- createUser这个变量取的很不理想，create是动词，createUser合起来就是创建用户的意思，而他这里要表达的意思是创建人的意思，所以应该叫createdUser或者creator；
- 为何originalItemFormat和originalItem的意思可以等价，不合理，如果等价，一开始就要命名为originalItemFormat；而且format是一个东西，动词放在最后，算个啥？
- 上面这个类的几个私有字段中，有些带命名空间，有些不带，要么都不带，要么都带；一般命名空间都是在上面声明，后续不需要出现；
- ILog logger；这一句有两个问题：1）logger为何没有下划线，不统一；2）为何类名叫ILog，而变量名叫logger，要统一，要么类名叫ILogger，要么变量名叫_log；
上面这两个私有方法，一个是大写开头，一个是小写开头，不一致，混乱；应该要一致；
通过上面的一些例子，我们知道，在我们不经意间，多写了一个空格或者一个空行，或者一个字母的大小写不一致了，都会导致命名的不一致；如果自己没有养成这种平时注重代码命名各种一致性的习惯，那写出来的代码很可能就是像上面那样。我觉得是非常糟糕的。上面我举的例子都只是简单的命名方面的，实际上还有很多其他的东西需要注意，最重要的就是我们必须要严格遵守：
- 你的任何一个属性的名字都要和其实际所代表的含义一致；
- 你的任何一个方法所做的事情都要和该方面的名字一致；
否则就会给代码带来极大的不可读性。
扫一扫
660
到【灌水乐园】发言
评论
准确地使用术语是确保团队所有成员在使用特定术语时始终遵循同一概念的重要因素。
首先，命名是必须的，因为没有命名无法沟通和写进文档。一个命名在A层次合适在B层次不一定合适，一个命名在A领域的解释和在B领域的解释可能是不同的。
同一个命名在不同领域的具体解释可能不同，但不管是在A领域还是B领域，这个相同的“命名”在这A B两领域中的具体解释必定是不与更宽泛的那个涵盖了A和B两领域的领域中的解释相冲突的。
对命名的使用具有分歧是非常正常的。不同人有不同的知识背景和知识结构。不同人的知识“结构化程度”“体系化程度”“良好程度”互不相同。
为什么有些命名使我们听起来那么地“惊奇”？这也很正常。为什么会有新命名？无非是因为重用旧的命名不能表达新的“意思”，无非是重用旧的命名容易为读者传递出“误解”。新命名很多时候是必须的，比如“云计算”这个命名，实际上它只是新瓶装旧酒。但“云计算”这个命名是非常有价值的，它的价值在于它抛弃了以往的众多“反模式”留下好的东西，忽略各种纷争，高高的发射一个明亮的“照明弹”到天上去。“云计算”这个名字取的好不好呢？不同人有不同的看法。“云计算”这个名字要是不好？那么微软和那些公认的大公司强团队取的诸如“犀牛”、“布丁”、“云梯”这样的名字好不好呢？
名字不是重要的。它只是一个代号。重要的是这个代号不能与已有的其它概念体系相冲突。“云计算”足够好了，它不跟任何其它体系相冲突。“犀牛”和“布丁”也足够好了，一个软件团队说“犀牛”时没人把它理解为经常呆在水里的那个丑陋的动物。
领域语言就是要统一。在项目干系人们沟通的各种上下文中去使用，重要的是一致性，一次没有传达出正确的意思没关系，这些命名会天天出现，各种相关文档、各种代码、各种面对面的沟通中都在使用。
比如“本体”，比如“命令”，这都是高度抽象的概念，但是听的多了慢慢的也就理解了，也就知道别人发出这些命名时他要表达什么意思了。一个良好的命名不与以往的知识相冲突，甚至也不与以后的知识相冲突，比如把“本体”这个命名放到其它领域甚至未来学习的知识中去权衡它依然有效，不会与其它公认的知识体系相冲突。
如果一个人的知识几乎完全地涵盖了另一个人的知识的话，那么这个人无论说什么那个知识结构更大的人都能明白他的意思的，即使这个人表达的意思不准确那个知识更多的人依然能明白意思。比如老外说中文，很多老外的中文说的并不好，但是我们依然能听懂。为什么？因为我们中国人对于中文的“语法“和”发音“知识早已了如指掌，远比老外多的多，所以老外发音不准确我们依然能懂（我们能够预想出和修正老外对”吃chi、ci“的发音）。