C++学习笔记----2、使用C++进行优雅编程(十)---- 格式化

        许多人因为编程风格的问题被搞得焦头烂额,就因为对于在if中使用几个空格争论不休,导致友谊的小船说翻就翻。如果公司有相应的编程规范,只能说你比较幸运。因为有可能你不喜欢这些规范,但做为一个正常人来讲,至少有规范可循,而不用因为这些东东而陷于无谓的争执之中。如果确实没有编程规范,我建议还是建立这样的编程规范为好,编程规范可以让大家使用统一的命名方式,格式化的规则等等,使代码统一化,易于阅读和理解。

        当然了,也有一些自动化工具,在将代码提交到版本控制系统之前,依据特定的规则进行格式化。有些IDE,比如Visual Studio 2022,当保存代码文件时,可以自动地格式化代码。

        如果你的团队当中,每个人都坚持自己的编码风格,要对别人宽容些。你会慢慢发现,有些只是喜好的问题,而有些则比较严重了,使团队合作陷于崩溃,还记得那天我给出的那个令人崩溃的小视频吗?

1、{}的位置

        可能争论最多的就是{}的位置摆放问题,至少有好几种对于{}摆放位置的编程风格,除了类、函数、成员函数之外,把{放到同一行代码的开始位置,看一下例子吧:

	void someFunction()
	{
		if (condition()) {
			println("condition was true");
		} else {
			println("condition was false");
		}
	}

        这样的格式,既保留了代码块的结构化,又使得代码紧凑而不显得臃肿,不失为一种好的编程风格。

        有些程序员就不怎么认可,认为{}与系统保留字之间的空格看着就不舒服,认为{}都应该单独占用一行,这样{}之间的对应也好找。看例子:

	void someFunction()
	{
		if (condition())
		{
			println("condition was true");
		}
		else
		{
			println("condition was false");
		}
	}

        很长一段儿时间,我都比较认可这种编程风格,好处是显而易见的,也在上面进行了描述,但仔细看来,当然是与第一种风格比较,把这些本来可以与其他行合并的{}单独占用一行,是否有必要,是否拉长了代码的长度,对于工程化的代码来讲,单页中的代码是否包含的内容相应减少,会不会扰乱或者分散阅读维护代码程序员的注意力与精力。当然了,这都是仁者见仁,智者见智的提法,不代表什么是正确,什么是错误。

        我们继续,基于上一种编码格式,有的程序员坚持认为单独占用一行的{}也应该进行水平缩进,当然了,除了类、函数与成员函数外,使得代码看起来像这样:

void someFunction()
{
	if (condition())
		{
			println("condition was true");
		}
	else
		{
			println("condition was false");
		}
}

        不得不说,这也是一种风格,至于怎么样,还是那句话,不比不知道,一比吓一跳,这也有点儿太做作了吧,但没有办法啊,有人就是喜欢啊。

        还有就是,有人认为,单独的一行代码是没有必要使用{}的,代码看起来是这样:

	void someFunction()
	{
		if (condition())
			println("condition was true");
		else
			println("condition was false");
	}

        看,如果是单独争论以上代码使用{}风格问题的话,这好像是一个完美的解决方案,看起来是这样啊,我不用{},总不会有{}使用格式的问题吧,但我要说的是,真的有问题,随着时间的推移,if、else中的代码要增加,如果没有{},一种可能就是写出了错误的代码,你默认其是在{}中的,潜意识当中原有代码的作者是把框架搭好了的,我不用去管程序结构的问题,前人种树,我来乘凉就行了。细心的程序维护人员会注意到这个问题,再把相应的{}加上。从我个人的观点来说,虽然盖房子的不需要考虑装修人员的事儿,但你总得把房子盖得干净利落吧,把结构还是给人搭好吧。

2、对于空格与括号的使用

        单行的格式也可能成为大家争论的焦点,我是不论谁是谁非的,但是你可能会遇到一些不同的风格,我们再讨论讨论吧:

        首先是空格的使用,在任何关键字之后要用空格,在任何的操作符之前要用空格,在参数列表或调用的每一个逗号之后要用空格,表明运算顺序的括号外面要用空格,看例子:

	if (i == 2) {
		j = i + (k / m);
	}

        另外一种方式,就是把if当作函数格式一样使用,在if与(之间不加空格,还有就是省略了明确标明运算顺序的(),因为它在语法上有或没有都是一样的,如下:

	if( i == 2 ) {
		j = i + k / m;
	}

        差别是微妙的,孰是孰非,就像武则天的无字碑一样,留待后人评说吧。当然,必需要指出的是,if不是函数,是判断语句的系统关键字。

3、空格、制表符与换行符

        对于空格与制表符的使用可不简单是一个风格喜好的问题,相信大家在编程过程中已经饱尝其苦了,如果没有好的编程规范,先不用说有的用空格,有的用制表符,就是对于制表符使用不同长度就会在代码中显得凌乱,简直不忍直视,我是深切地体会到这一点的,我曾经用我设置的编译器打开别人的代码,我们对于制表符的设置完全不一样,代码像一团乱麻,完全无法阅读,更无法帮助别人查找代码的bug,由于我们分属不同团队,无法说谁对谁错,只能说不同的规则给团队合作带来了太多的内耗。

        并不是所有的编辑器都支持对制表符长度的定义,所以是用制表符还是用空格,其实不是一个需要讨论的问题,因为谁也不愿意写代码时啪啪啪啪敲四个甚至更多空格,太劳民伤财了。但需要记住的是,在程序中空格就是空格,制表符就是制表符。

        还有一个就是换行符,换行符在不同的编程环境下面是不同的,在Windows环境下,换行符是/r/n,在LINUX环境下就是\n,如果大家在不同的编程环境下协作开发,建议大家还是约定一下,不要因为这些小节影响开发进度,当然了,大家也很清楚,大的问题都是这些小的小节引起的,还是中国的老话说得好啊:千里之堤毁于蚁穴。

4、编程风格的挑战

        许多程序员在开始一个新项目时,都会发誓说这次我一定要把所有的事情都做对,不论何时,如果一个变量或者参数不会被修改,就要定义成const,所有的变量都要有明确的,准确的可读的名字,所有的开发者都要把{放置到第二行的开头,应用标准的编辑器,对空格与制表符进行规范,等等等等。

        其实吧,由于一些客观原因,以上发誓要遵守的这些编程风格实际上很难坚持,你还别不信,当然了,我不是不相信你的毅力,我说的是实际上,是客观上,不以你的意志为转移的,还是举例说明最好使,那就举例吧,假如有一个你一开始认为不会在程序中改变的值,你把它定义为了const变量,在你所写的代码中,一直坚持下来了,但突然,你要把这个值当作参数传递给要调用的外部函数,而外部函数中对这个参数的定义不是const的,你怎么办?当然外部函数肯定也不会改变这个参数的值,要求外部函数修改参数定义,不可能的,白日梦还是不要做了,当然,如果你经验足够丰富,是个老手,并不是不能完美解决这个问题,只需要使用const_cast()临时将其const属性去掉,但如果你没有这方面的经验,怎么办呢?只能是将const属性去掉,并且,基于这样的经历,你会将之视为财富,所有变量都不会再定义成const的,别人问你时,你还把这个案例当作痛苦的经验教训告诉别人,说你不用const是事出有因的,殊不知,是你的能力限制了你的创造力,而积累的又不是宝贵的成熟经验,唉,一言难尽啊。

        有些时候,标准化与程序员自身的喜欢与基础背道而驰,使用严格的编程规范与团队文化也格格不入。在这种情况下,你可能就要想办法了,走中间路线,和而不同,诸如此类吧,其实你懂得,说白了,就是不要看广告,要看疗效呗。像变量命名与制表符长度,这些是一定要坚持的;而像使用空格了,注释的格式了,就根据个人喜好自己定吧。当然你也可以利用外部或者自己写一些脚本来修正其不规范的格式,当然了,也有开发环境能够自动格式化相关代码的,如Microsoft Visual Studio 2022,使用这样的利器,就可以将按规范写代码变成了微不足道的小事。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

王俊山IT

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值