关于清洁代码的规范性疑问

[圣殿骑士18]

看过一些关于代码封装的规范的书，不乏一些国外大牛的书，我印象比较深的比如：一个函数的代码不应该超过20行。
我是从来没有遵循这个规则，也不太能理解为什么要这样做的原因。我自己始终觉得“业务完整性”的表述更重要。比如一个“业务”实现的代码，如果要通过多个函数，甚至于多个逐层调用的函数来完成，这种业务代码在我来看，是很难阅读的（需要不断的进入/跳出函数，这很打断思路），所以我自己的习惯始终是，一个“业务”的代码，顺序读下来，代码间分段明确，注释足够，阅读效果是最好的，几百行代码读起来完全不费劲。

当然，我以前不太写c代码，我写的是c#这种代码，使用的是VS这种高级IDE，是不是这种高级语言和高级IDE下，代码规范如我这样写更好？我也只是猜测。

最近在看一个历史项目的c代码，把我这个疑问又勾起来了，我把它作为案例，拿出来问问大家。
它是这样的，在一个实现中，封装了七八层函数，这些函数都只被调用过一次，也就是函数封装起来只是被一个地方调用。那我就奇怪了，这样的话封装起来干嘛？封装起来不应该是为了“复用”吗？

这些函数，依次被调用，且仅调用一次：
parseVarBind()
parseSequence()
parseSequenceOf()
parseRequest()
parseCommunity()
parseVersion()
parseSNMPMessage()
SnmpXDaemon()

代码类似：

SnmpXDaemon()
{
	//一些代码
	parseSNMPMessage()
	{
		//一些代码
		parseVersion()
		{
			//一些代码
			parseCommunity()
			{
				//一些代码
				parseRequest()
				{
					//一些代码
					parseSequenceOf()
					{
						//一些代码
						parseSequence()
						{
							//一些代码
							parseVarBind()
							{

							}
							//一些代码
						}
						//一些代码
					}
					//一些代码
				}
				//一些代码
			}
			//一些代码
		}
		//一些代码
	}
	//一些代码
}

请问：
这种封装方式，每个函数的代码量是不多，每个函数不超过50行，但
1、这种封装方式合理吗？
2、如果合理，为什么合理？

[圣殿骑士18]

引用 6 楼 taodm 的回复:

现在没有复用、修改不代表以后也不会。所以，作为一个好习惯，就是总为复用、修改留下余地。 你这个有点类似：现在马路上又没车，你为啥不闯下红灯。对错、好坏自己判断。

我的看法，是刚好相反的。这是我做产品时总结的：简洁的设计，不要过度设计产品，让产品生长，而不是设计。我个人认为代码也应该如此，代码的封装不要过度设计，以为未来会如何如何复用，其实往往最后就没有复用。这个案例就是如此，产品定型了，也没有复用。 我认为好代码也应该是，根据需求迭代出来的，那才是最简洁的代码。不要怕未来改代码，未来在迭代时有复用需求了再复用。

[圣殿骑士18]

引用 6 楼 taodm 的回复:

现在没有复用、修改不代表以后也不会。所以，作为一个好习惯，就是总为复用、修改留下余地。 你这个有点类似：现在马路上又没车，你为啥不闯下红灯。对错、好坏自己判断。

我这么说的意思，也不是说我自己想闯红灯，其实我对代码整洁也是有追求的，我只是觉得有些时候不应该过度设计。不是说要在路口闯红灯，而是比如50年前，大家都在用手推车的时候，十字路口不需要设置红灯。

[lin5161678]

既然如此你不應該有疑問 你的體驗就是都寫在一起方便你就都寫在一起 相信自己

[lin5161678]

反正我的體驗是封裝了更方便 大家敬而遠之

[走好每一步]

觉得不用死守着超过50行就要拆，有的如果真的没必要拆，就留着吧 但是如果一个函数动不动就几百行，这个肯定是不好维护的

[taodm]

你认为已经过度了，大师们还嫌不够。你认为以后可以重构/重用，大师们认为以后根本不会给你这个时间、机会。 所以，这样多讨论是没有结果的。 自己理解，自己成长，走自己的路。

[qybao]

除了代码重用，扩展，还有一个作用，就是方便单体测试
如果只改动了某个函数，单体测试之要测试该函数就可以了，写在一起就要整体测试（相当于结合测试了）
当然，至于怎么划分模块合理，那就具体问题具体分析了。

[圣殿骑士18]

引用 13 楼 taodm 的回复:

你认为已经过度了，大师们还嫌不够。你认为以后可以重构/重用，大师们认为以后根本不会给你这个时间、机会。 所以，这样多讨论是没有结果的。 自己理解，自己成长，走自己的路。

是的，路还是要自己走出来的。

[圣殿骑士18]

引用 14 楼 qybao 的回复:

除了代码重用，扩展，还有一个作用，就是方便单体测试 如果只改动了某个函数，单体测试之要测试该函数就可以了，写在一起就要整体测试（相当于结合测试了） 当然，至于怎么划分模块合理，那就具体问题具体分析了。

单元测试，这点，不可否认。几百行的代码，确实对单元测试来说是很糟糕的。如果有一票否决，那么这个理由比较充分。不过同时，做好单元测试的程序员少之又少，及其优秀的项目，可能才会考虑到单元测试这么完善。

[圣殿骑士18]

总结起来说，我也不是说就是不认可大师们的观点，大师们这么做应该有他们的道理，只不过我从自己的经历来说，不能体会到这样做有那么多的好处，反而缺点挺多。而我也想想明白了再干，不想盲从。 我能想到的几点，需要短函数的原因是： 1、单元测试：测试单元越短越好。 2、低级语言：比如c/c++这种稍低级的语言，涉及到比较多的运算，代码相对的不那么容易看懂，封装有利于功能的模块化和理解。而我使用c#等高级语言多了，这些高级语言表达力强，即使写上100行，其阅读性也还是非常强。所以相应的对短函数的要求降低了。 以后会尝试写短一些的函数和方法，更深入的体会一下短函数的优缺点。

[赵4老师]

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

[greens chicken]

代码抽出来，我感觉主要作用，维护方便。比如我要往list里面加1-100和a-z。不用循环那种添加。这时候抽出来两方法，一个加数字一个加字母。输出时候缺数字，我就直接去看加数字那个方法。就没必要把加字母那个也看一下了。尤其是你接手别人代码时候，我之前接手别人东西时候，有个方法四五百行，密密麻麻。我看着头都疼。

[走好每一步]

引用 18 楼 wangshutong0907 的回复:

代码抽出来，我感觉主要作用，维护方便。比如我要往list里面加1-100和a-z。不用循环那种添加。这时候抽出来两方法，一个加数字一个加字母。输出时候缺数字，我就直接去看加数字那个方法。就没必要把加字母那个也看一下了。尤其是你接手别人代码时候，我之前接手别人东西时候，有个方法四五百行，密密麻麻。我看着头都疼。

四五百行算少了，有点上千都有，哈哈 不过我一般保持在一个屏幕到2个屏幕之间，超过2个屏幕的一定拆了

[greens chicken]

引用 19 楼 走好每一步的回复:

[quote=引用 18 楼 wangshutong0907 的回复:]代码抽出来，我感觉主要作用，维护方便。比如我要往list里面加1-100和a-z。不用循环那种添加。这时候抽出来两方法，一个加数字一个加字母。输出时候缺数字，我就直接去看加数字那个方法。就没必要把加字母那个也看一下了。尤其是你接手别人代码时候，我之前接手别人东西时候，有个方法四五百行，密密麻麻。我看着头都疼。

四五百行算少了，有点上千都有，哈哈 不过我一般保持在一个屏幕到2个屏幕之间，超过2个屏幕的一定拆了[/quote] 四五百行看下来，脑阔都炸了。是上千行在一起的直接起飞🛫

[圣殿骑士18]

引用 19 楼 走好每一步 的回复:

[quote=引用 18 楼 wangshutong0907 的回复:]代码抽出来，我感觉主要作用，维护方便。比如我要往list里面加1-100和a-z。不用循环那种添加。这时候抽出来两方法，一个加数字一个加字母。输出时候缺数字，我就直接去看加数字那个方法。就没必要把加字母那个也看一下了。尤其是你接手别人代码时候，我之前接手别人东西时候，有个方法四五百行，密密麻麻。我看着头都疼。

四五百行算少了，有点上千都有，哈哈 不过我一般保持在一个屏幕到2个屏幕之间，超过2个屏幕的一定拆了[/quote] 一两屏，我也差不多这个尺度。

[圣殿骑士18]

引用 20 楼 wangshutong0907 的回复:

[quote=引用 19 楼 走好每一步的回复:][quote=引用 18 楼 wangshutong0907 的回复:]代码抽出来，我感觉主要作用，维护方便。比如我要往list里面加1-100和a-z。不用循环那种添加。这时候抽出来两方法，一个加数字一个加字母。输出时候缺数字，我就直接去看加数字那个方法。就没必要把加字母那个也看一下了。尤其是你接手别人代码时候，我之前接手别人东西时候，有个方法四五百行，密密麻麻。我看着头都疼。

四五百行算少了，有点上千都有，哈哈 不过我一般保持在一个屏幕到2个屏幕之间，超过2个屏幕的一定拆了[/quote] 四五百行看下来，脑阔都炸了。是上千行在一起的直接起飞[/quote] 以前写数据库存储过程，有个别人写的两三千行代码的，维护的非常痛苦。别说，这还是别人优化过的，以前是每个业务单独的，但维护的人觉得代码不够复用，结果全写一块了，最后证明是过度封装了。

[走好每一步]

过度使用设计模式那种代码看起来也蛮痛苦的

[赵4老师]

自创C语言填表式编码风格。欢迎大家用各种语言及其编码风格来PK！ https://bbs.csdn.net/topics/380157851

[圣殿骑士18]

引用 24 楼 赵4老师 的回复:

自创C语言填表式编码风格。欢迎大家用各种语言及其编码风格来PK！ https://bbs.csdn.net/topics/380157851

太特别了，不太能接受

[顾小白xx]

我写代码其实没有一定要拆分，但是如果有一个功能比较特别但是它属于中间环节，就像是一个产品的原料，你虽然可以在一个函数中组装出来一个产品但是如果别的地方也需要这个原料那么你拆分出来的函数就有用了，还有一种情况就是，你组装的产品有需要变更一下形状或者颜色，那么起关键作用的就是哪个原料怎么办，你不能再每个用到这个原料的地方都改一下吧。