程序员：这10种糟糕的程序命名，你遇到过几个？

目录

01 措不及防的缩写 02 中文命名 03 自己的姓名来命名类和方法 04 加了魔幻的方法命名 05 歧义的命名 06 数字化的命名 07 考验眼神的命名 08 直接以类型来命名 09 不规范的方法名 10 单词拼错的命名 有人问：规范的命名风格真的能让你程序员少出bug？ 当遇到这方面的教训时，就会想到这句话还是有点道理的。 工作快三年多了，从刚开始的什么都不懂，到慢慢发现积累知识点的重要性。关于程序的命名规范之前也做过一些笔记，只是感觉不全面，就一直没有写出来。

曾经刚工作的时候，命名也挺随意的，现在看起来，都有点想打过去的自己。总有这样的一个过程，有些知识点，在潜意识里并不知道要去了解深入它。

01 措不及防的缩写 一般来说如果单词过长的话，会采用缩写的方式，比如number 》num CurrentUser>currUser。可是工作中，经常会遇到这种“便秘式”命名，给人一种措不及防的感觉。有时候还要利用想象的空间的，猜一下这个命名到底是个什么玩意。 写完整的算了，他不他偏要来个缩写，缩写后，我就看不懂（本身就不长，干就万事了。） 这是一段xaml引入命名空间的代码，一个6个字符，缩写后成功地变成5个字符，最终为大家节省了点击一个键的卡路里。common完美缩写成comon

xmlns:comon="clr-namespace:SGS.SIO.Common.Utilities;assembly=SGS.SIO.Common" 建议：缩写干脆点，实在想不到好的缩写，那就直接写完整的单词

02 中文命名 （ps:无法展示类似代码.png)不要觉得中文命名不可思议，我以前也是这样觉得居然还有中文命名的，上一家公司就有这样的例子。工作一段时间后，你可能会遇到一些几年前甚至十年前的代码，什么是工作啊？工作嘛...... 每一种存在，都有他的存在的理由（ps：不管是好还是坏）。我的思考是，上一家公司采用中文命名是有一定的原因的，那些名词如果英文来翻译的话，非常容易歧义、难以理解、甚至跑偏，工作嘛，不能改变的时候，就只能去接受它。 建议：不要使用中文命名，万不得已的情况下也不要，打上注释也行啊

03 自己的姓名来命名类和方法 这一case来自邹溪源老师文章成就卓越代码,从关注细节开始的第一段落 用自己姓名来命名，我是真没遇到过，邹老师是一位80后程序员，见多识广。所以碰到过这样case，我就分享一下

///

/// author:zhangsan ///

class ZhangsanTest { private void TestGetData() { int a, b, c; } private int ZhangsanGet(int s1, int s2) { int s3 = s1 + s2; return s3; } private List GetData() { return null; } } 这是一个喜欢用自己的姓名来命名类和方法的作者，在他的代码中，经常可以看到这样奇怪的对象定义，而且他还喜欢用a,b,c,d,e,f或者s1,s2这样的命名，仿佛他的代码自带混淆特效。这样的代码嗅起来会不会觉得充斥着奇怪的味道？

建议：名字来命名这事儿挺严肃的，毕竟后面接手的人可能会认识你这个沙雕

04 加了魔幻的方法命名 private void GetData() { int a, b, c; } 这个我是真的见过，看到邹老师分享，我抽了根烟，相见恨晚.png。

另外，有没有发现有许多开发者喜欢用 GetData() 来定义获取数据的方法？然后这个方法就成为一个万金油的方法，不管是爬虫采集、或者数据绑定，无论是 C# 写的后端或者 Java 写的后端代码，或者用 vue 写的前端代码，仿佛在任何场景、任何数据应用都可以看到这样的方法。 如果一个项目中，有十几个地方都出现了这个** GetData() **方法，那种感觉一定非常难受

熟悉的名字，却是千变万幻的味道。 建议：这不是写那个GetData的码农吗？你品，你细品！

05 歧义的命名 这也是我遇到的真实案例，为此付出了无意义的1个小时调试。将一个页面的命名成this，可能觉得this好用，this挺喜欢好用。 比如这个：

x:Name="this" 调用的时候

Command="{Binding Source={x:Reference this},Path=BindingContext.EditCmd}" 当时就有点懵逼，这个this到底指的是什么。这种以关键字来命名的，估计是想报复同事。 良好的命名如这样的：

建议：禁止使用关键字来命名

06 数字化的命名 不要觉得，这事我最多也就上学时候干过。 全面发展，数字一体化。的却挺全面，曾经做xamarin的时候，在一个activity的里面有5，6个按钮，点了一个其他按钮显示不同状态，于是每个按钮变成dialog1、dialog2、dialog3 建议：根据实际的作用进行命名。

07 考验眼神的命名 int materialFirstNum = 8; int materialSecondNum = 11; int materialSumNum = materialFirstNum + materialSecondNum ; 欢迎大家来找茬，良好的命名变量是让人一看就明白，顾名思义。把不同的部分写在中间，书写时容易了，但是不容易检查。（ps：这里指的书写容易指的是写material时，各种IDE会有提示） 比如这样：

int firstMaterialNum = 8; int secondMaterialNum = 11; int sumMaterialNum = firstMaterialNum + secondMaterialNum ; 建议：如果有相似的名字，请把他们不同的部分卸载开头，其次是结尾。

08 直接以类型来命名 List list =new List(); string[] array = { "","",""}; 这种名字不好的地方有两个

命名根本就不知道代表什么意思，毫无意义 IDE提示也容易混淆，不容易输入 有经验的程序员肯定会写出这个变量是代表什么意思的，比如这样的 List materialList =new List(); string[] titleIdArray = { "","",""}; 建议：不要写与系统定义类型关键字的命名，命名要有意义。

09 不规范的方法名 比如这个命名：

public static int TwoNumSubtraction(int firstNum,int secondNum){ return firstNum - secondNum; } 最好改成 动词+名词格式，subtraction的缩写sub，这样的好处是合适的缩写顾名思义，SubTwoNum就知道是做两个数的减法运算。

public static int SubTwoNum(int firstNum,int secondNum){ return firstNum - secondNum; } 建议：方法名最好动词+名词格式

10 单词拼错的命名 SendMassage(...)看到这个，我感觉当时这哥们应该压力挺大的。 data和date 组合拳式混写，可能当时这个当事人自己也写蒙了吧！ form、from 。这个我也曾经常容易写错，傻傻分不清！ dataOne, dataTwo, dataThree, DataFour (手动捂脸) 建议：这个我真啥建议的.....

结语：林子大了，什么鸟都有！最后问一句，什么是工作啊？ 下篇会写到，代码命名方式有哪些？代码规范会写成一个系列

最后，小编想说：我是一名python开发工程师，整理了一套最新的python系统学习教程，想要这些资料的可以关注私信小编“01”即可,希望能对你有所帮助.