[图片] 有人问:规范的命名风格真的能让你程序员少出 bug? 当遇到这方面的教训时,就会想到这句话还是有点道理的。 工作快三年多了,从刚开始的什么都不懂,到慢慢发现积累知识点的重要性。关于程序的命名规范之前也做过一些笔记,只是感觉不全面,就一直没有写出来。 直到前段时间看了邹溪源老师的这篇成就卓越代码,从关注细节开始 ..

程序员:这 10 种糟糕的程序命名,你遇到过几个?

有人问:规范的命名风格真的能让你程序员少出 bug?
当遇到这方面的教训时,就会想到这句话还是有点道理的。
工作快三年多了,从刚开始的什么都不懂,到慢慢发现积累知识点的重要性。关于程序的命名规范之前也做过一些笔记,只是感觉不全面,就一直没有写出来。

直到前段时间看了邹溪源老师的这篇成就卓越代码,从关注细节开始
引发了我的感触,再不总结,都快 2020 年了,头发都掉了不少。

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

image.png

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,我就分享一下

/// <summary>
/// author:zhangsan
/// </summary>
class ZhangsanTest
{
    private void TestGetData()
    {
        int a, b, c;
    }
    private int ZhangsanGet(int s1, int s2)
    {
        int s3 = s1 + s2;
        return s3;
    } 
    private List<string> 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 到底指的是什么。这种以关键字来命名的,估计是想报复同事。
良好的命名如这样的:

<CheckBox x:Name="chkBoxChinese" /> 
	<Label Text="chinese">
		<Label.Triggers>
			<DataTrigger TargetType="Label" Binding="{Binding Source={x:Reference chkBoxChinese}, Path=IsChecked}" Value="true"> 
			<Setter Property="FontAttributes" Value="Italic, Bold" /> <Setter Property="FontSize" Value="Large" /> 
			</DataTrigger> 
		</Label.Triggers> 
	</Label>

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

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<MaterialModel> list =new  List<MaterialModel>();
string[] array = { "","",""};

这种名字不好的地方有两个

List<MaterialModel> materialList =new  List<MaterialModel>();
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 (手动捂脸)
建议:这个我真没啥建议的…

————————————————
版权声明:本文为 CSDN 博主「dotnet 全栈开发」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/kebi007/article/details/103450528

回帖
请输入回帖内容...