谭浩强的书我就不说什么了，居然教学生include一个.c文件

shan_ghost

呵呵，昨天写的个回帖，本来不想贴出来了。不过看到很多被夹的 “非此即彼” 的黑白脑袋，感觉还是有贴一贴的必要

原帖由 prolj 于 2009-10-28 12:04 发表
设计相当重要，代码量大并不能说明什么，我把一个十万行的模块消减到1W行了。
不知道村长的项目为什么include c，但是，我想表达，实际工程中要尽可能的简单，因为每一行代码都是自己日后的负担，该用的手段就 ...

我也会用，哈哈


比如以前遇到过一个项目，把所有.h文件都集中放在一个目录——这情况俺改变不了。
那么这时候，如果遇上村长的情况，俺估计也会直接动用 include .c或者 include .inc之类手段，谁让他们的源码管理那么水呢


窥探系统的内部实现，通过奇奇怪怪的手段实现功能，几乎是每个有一定经验的程序员都干过或正在干的——根源一般都来自愚蠢的总体设计或意料之外的特殊情况或程序员自己对相关领域的不了解。

不过，一般这种地方，俺都会重点测试，并且加上这样的注释：
//!!!WARNING!!! 吧拉巴拉写一堆说明
//!!!HACK!!! 吧拉巴拉写一堆理由
这样以后有了时间，或者有了新的认识，只要搜一下三个叹号就可以回来改掉。


总之，某些做法是正常的，某些做法是异常的。也许知道了更多东西，异常的做法就能被更好更规范的做法替代，也可能找不到替代办法，或者发现异常做法其实就是业界在类似情况下的标准做法；甚至是虽然有替代办法但不想支付改变的代价，因此仍然坚持了异常做法，这些都是正确的处理方法。

关键问题就是：必须要知道什么样的做法才是正常的，必须训练自己，保持对“坏味道”代码的敏感。
如果丧失了这种敏感，甚至是从一开始都没训练出这种敏感——那么这种程序员就太可怕了。



具体到这个例子上，include .c就是最典型的“邪恶”用法；或许在某种情况下迫不得以要用，但记住这种做法是必须严格控制扩散范围的、甚至是见不得人的、贻笑大方的。

再次强调一次，include .c并不提供任何功能。include .share .inc .c_part 等等都同样能达到同样的效果。

正如村长之前所说的，不用.share而用.c，仅仅是因为.c可以自动在编辑器中语法高亮——这就是抛弃.h这个一般规范换来的唯一好处。

当然，如果知道这种做法肮脏、邪恶，并且知道要严格控制这种做法的使用范围，那么在这个大前提下，它并不会造成太大太恶劣的影响。
那么，这时候，节约一个点开自己的编辑器配置菜单，把.share或.c_part也关联为c语言源代码的沉重代价，破坏一下关于.h的一般约定，当然也不是什么大不了的。

——这就好像你路过某美女身边，无意间顺着人家衣领子看了进去，大大的暗爽了一把：这种行为虽然不对，但男人嘛，理解。
——可是如果以后你天天乔装改扮动用各种先进技术器材去窥探女澡堂，那就不能不说阁下的心理出现比较严重的问题了。

shan_ghost

我日，看来以后必须用 UUID 来当函数名前缀了。

算了，以后不来这个帖子里掉价了。

shan_ghost

原帖由 orclover 于 2009-10-29 19:59 发表
感觉大家过于激动了，就事论事，不要上升到对人的质疑，毕竟建立一个高质量社区很不容易，如果大家意见不合就“文人相轻”，那么最后的结果只能是“树倒猢狲散”。

这个提议很好，可惜你什么都没看到。

问题的关键就是： .c 和　.share　究竟有没有差别？如果有，那么差别在哪里？如果没有，那么凭什么说.c就能解决函数重名问题而.share就不可以？


至于是谁绕老绕去不说准话，甚至很没品的把问题拉到“xx在下很大很大的一盘棋”上，并以此压制，让其他“没下过很大很大的一盘棋”的不明真相的网友闭嘴？


一旦绕到“我下的是很大很大的一盘棋”上，而对最基本最显然的事实选择性失明，这种讨论不堕落到泼妇骂街是不可能的。

——我在下很大很大的一盘棋，你根本不明白我要解决什么。
——其实我很明白。

——另一个网友说，我下的棋也很大很大，解开２Ｇ，压缩后５００Ｍ
——对方辩友回答：很大的棋难度不一定大，５０００Ｇ的一盘大棋我都优化到了１Ｍ

——吹吧，把你的棋贴出来
——没吹。把你的先贴出来
——我贴出来要坐牢的
——没胆了吧？
——你有胆你先贴。
——你先给我找能放５０００Ｇ资料的服务器
……
……
……
……
——小样，我的棋有一万个子
——切，我的棋上不着天下不着地
……
……
——我的棋盘大的，整个公司连一个乒乓球都塞不进去了
——那你怎么进去？
——手伸进去就行了。
——那你的脸呢？
——吹牛的人还要脸干嘛。


恩，这种争论真的很有意思。

shan_ghost

34楼和87楼难道被版主隐藏了？