主要是基于最近Quora上的跟帖讨论,根据你们的反响和投票结果,有一项投票遥遥领先,稳居第一。对于软件开发人员来讲,最大的难题是:如何命名(例如:给变量,类,函数和过程命名等等)。html
对于这个结果,我多少有点意外,由于做为一个多年的开发人员,我不会投给这一项(我想我会投给“修改或维护别人的代码”)。可是真正让我惊讶的是,看起来好像不怎么重要的命名竟然排列第一,跟期待的结果实在差太远了。下面是投票结果的分布图。git
该结果是来自Quora问答网站和更早的Ubuntu论坛跟帖的4500个开发者的投票。如何命名一项的选票几乎是其它八项的投票结果的总和,哇!程序员
的确,这些基于自我筛选的群体的投票结果是彻底不科学的。可是我认为这个结果仍是有必定意义的,换句话说,如何命名的确是个很棘手的问题,许多非编程人员可能会意识不到。
Don’t go into programming if you don’t have a good thesaurus 比较旧以前的调查,能够对比看看github
“一般,若是你没法想出一个合适的名字,意味着你的设计可能有问题。你的一个方法里是否是实现了太多的功能?或者你的类的封装,凝聚性不够强?” 编程
“个人经验是若是没法给你的类想出一个合适的名字,大多数状况都是你的类有问题:你可能不须要这个类,它有点多余了” 数组
“命名难也不见得是坏事儿,它能够迫使你去认真思考你的类到底想要实现什么功能。”bash
List定义的变量应该 List 做为后缀结尾。
Map定义的变量应该 Map 做为后缀结尾。
数组定义的变量应该 s 做为后缀结尾。
类成员变量是用 m打头。微信
遵循当前语言的变量命名规则,不要不统一(inconsistently)地使用大/小写字母。例如:userName, UserName, USER_NAME, m_userName, username, …。
以Java为例:ide
在同一个类不一样的场景(contexts)中不要复用变量名。例如在方法、初始化方法和类中。这样作能够提升可读性和可维护性。函数
不要对不一样使用目的的变量使用同一个变量名,而是赋予它们不一样的名字。这一样对保持可读性和可维护性很重要。
变量名不要使用非ASCII字符(non-ASCII chars)。这样作可能会在跨平台使用时产生问题。
不要使用过长的变量名(例如50个字符)。过长的变量名会致使代码丑陋(ugly)和难以阅读(hard-to-read),还可能由于字符限制在某些编译器上存在兼容性问题。
仅使用一种天然语言(natural language)来命名变量。例如,同时使用德语和英语来命名变量会致使(理解)不一致和下降可读性。
使用有意义的方法名。方法名必须准确表达该方法的行为,在多数状况下以动词(verb)开头。(例如:createPasswordHash)
遵循公司的方法命名规则,在项目中坚持使用同一种方法命名方式。例如 getTxtUserName(), getLblUserName(), isStudentApproved(),不然会对可读性形成影响,并且会令查找/替换工具不可用。
遵循当前语言的变量命名规则,不要不统一地使用大/小写字母。例如:getUserName, GetUserName, getusername, …。
以Java为例:
使用有意义的方法参数命名,这样作能够在没有文档的状况下尽可能作到“自解释(documentate itself)”
更多详情能够了解:命名约定:zh-google-styleguide.readthedocs.io/en/latest/g…
老手应该都知道codeif了吧,新手能够收藏一下。
支持直接搜索中文,当你查中文的时候,Codelf 会直接查好单词和单词的近义词给你,而后再搜索Github, Bitbucket, Google Code, Codeplex, Sourceforge, Fedora Project上的开源项目的源码匹配出与这些词汇相关的变量名和函数名。Codelf 能够选择开发语言进行搜索,结果会把同个源码文件里匹配的变量名排在一块儿,如你选择“PHP”而后搜索“支付时间”
Codelf: unbug.github.io/codelf/
微信扫描二维码,欢迎关注个人我的公众号:daimajiqiao
分享技术文章,代码技巧复制代码