以其昏昏，使人昭昭？

蔡万钊

有的人自以为写过很多代码就藐视别人，诶～

说实在的， 这种人比 THQ 还可怕。

starwing83

回复 3707# OwnWaterloo


    本来看得很欢乐，发现扯到我身上了……

我声明一下，那些代码是业余兴趣，而且是为了improve一个现有模块，所以我写的也是比较用心的。

一开始设置了一个“平台抽象层”（每个平台必须实现的很函数），为了效率等等（同translation unit的static能优化——当然这不是大不了的事情，这年头lto也可以优化非static函数的），我在一个文件里面写了所有平台的代码。后来发现似乎有点大，滚动起来不舒服，就想起来村长的那个方案，分解成了几个.c然后include，感觉——挺舒服的，因为各个.c的结构大致相同，也在一个地方包含，名字也有规律，觉得这样是个比较好的解决方案——除了具体的PAL（平台抽象层）比较隐晦以外（额，我马上就去改，加几个prototype）。

goto那个，我一直觉得正常使用goto是一件很正常的事情（这么正常的一句话听起来像废话= =），我从来不觉得goto有什么问题，是滥用goto有问题。在21世纪，在C语言有充足的控制逻辑（if，do，while，for，函数调用）的前提下，面条式代码本来就不太可能，谨慎使用goto足够了。面条式的前提说的是只有行号和GOSUB的BASIC，那货早期可是连函数都没有的，我们调用函数都是let a = 1, b = 2 : goto 100 这种的…………

总的来说，我觉得村长的方案的确是挺舒服的——这个认知建立在我的项目很小（目前根本没makefile），而且我不愿意维护构建系统的基础上的。include .c的确可能是误用，然而如果你去想了“误用”这个问题，我相信你就不是误用——最多也就是估计错误而已。

starwing83

回复 3743# pmerofc


    其实是这样子的。教科书需要告诉读者，什么是规则，而读者更需要明白，规则是可以打破的，村长在自己的项目里面这么做有没有错我不知道也没法知道，但是教科书不能这么写，本来教科书就必须比正常项目严格。不过。如果项目维护人思考过应该这么做，你却不能以教科书的要求去指责他，这样是不对的。

蔡万钊

简单的一个问题都能吵架，真是无聊的人啊

简单的来说，凡是不规矩的都是   “USE AT YOUR OWN RISK”

没有什么好不好。pmerofc 提出的说法其实是，教科书可以告诉你 include .c , 但是教科书一定要明白的告诉你，这是非常不好的风格，“USE AT YOUR OWN RISK”。

这就对了。

至于村夫为什么会吵架，真不明白这种人。
他先是说没有比 include .c 更好的办法。我提出一个可能的办法，看是否可以采用，并没有说必须用我的办法。这家伙就爆跳如雷了。
只能说，这种人其实是极度自卑的人。

蔡万钊

回复 3749# pmerofc

希望这个是你 YY 出来的