chapter 2 变量 —— 变量的命名

晚了一天，但在这博主还是祝能看到此篇博客的同学“端午安康，平安喜乐”！！！（这两天朋友来，玩嗨了……）

今天先说变量的命名，最被大家熟知的应该是“大小驼峰命名法”和“匈牙利命名法，例如：

大驼峰：PrintMyName

小驼峰：printMyname

匈牙利：print_my_name

以上三种，不能说谁好谁坏，全凭个人习惯、喜好，在就国内的整个计算机语言大环境来说（我猜的），现在来看好像是“小驼峰”更胜一筹。

但在诸多Python文献（其实我也没看几本书）中好像是“匈牙利”更受欢迎，可能是老外更喜欢匈牙利一些，在许多的开源库中也有一些体现。

但其实不管是变量、函数、类等等的命名，你用“大小驼峰”或是“匈牙利”再或者一些其他的规范，只要你们简洁明了的表达出其含义，就是成功的。有一些公司也会规范员工的命名，在这个时候，最好还是按照公司的要求来，因为公司这样可以更好的管理代码，如果你实在是想突出自己的个性，那就一定要把代码写好，不要留坑，尽量优化，否则出现bug，就能一眼就找到你，毕竟你是最特别的。

当然，自己平时一直能注意到命名这方面的问题是最好，有时候代码的可读性可以间接的反映出一个程序员的整体素养（尤其是面试第一分程序员的工作时，哪怕上机没能实现功能，代码好看也是一项竞争力）。毕竟代码里全是用a B c D来命名的代码，真的没几个人愿意看，哪怕你代码写的再好。程序员最烦的是写注释，然后就是读之前员工留下的代码！

如果有一天，你加入了一家公司，发现该公司并没有对代码的命名做要求，也没有做代码管理，那么你的机会就来了。如果你能把代码的规范和管理推动并实施下去，我想即使你之后离开公司，那些新加入的员工也会记着你的这份功劳！

好像扯的有点远了……

如果在今后的代码里真的是不想写那些注释，可以从命名上做写文章，最起码能让别人有能读下去的信心。但如果老板不是东西，你可以在关键代码中命名随意一些，保证自己第二遍也看不懂就好，离职之后美滋滋（但真的”可以，但没必要“）。

一份好的代码，不仅仅是功能强、效率高，在细节的地方更能见微知著，个人觉得命名能占很大的份额。就像是一本好书，不仅能教会一些什么，每一句都会精雕细琢，大有深意……

所以，大家把什么有道、金山、百度等翻译都用起来吧，嘿嘿嘿……