以其昏昏，使人昭昭？

OwnWaterloo

蔡万钊 发表于 2012-07-31 17:17
我当然知道啥意思啦～～ 有时候这确实是比较难取舍的东西。 但是 include .c 绝对是傻逼行为。哪怕换个扩展名呢！

换扩展名的方案，村夫认为是同一种 —— 包含文件里带有定义，而非仅仅是声明。
用.c只是为了更容易让编辑器按C语言高亮。


另：为什么include .c就绝对傻逼了？你能找出让人（或者说我）信服的理由？
只要了解我前面说的C语言规定的那3点（定义与声明、linkage、one definition），include .c完全符合C语言定义（不符合的仅仅是一个习俗），任何编译器上都会有相同的行为。

或者换种说法，你能接受换个后缀名？比如inl？
同样的行为 —— 包含带有定义的文件 —— 仅仅是后缀名从inl改成.c的不同，后者就绝对傻逼了？

OwnWaterloo

pmerofc 发表于 2012-08-01 08:59
回复 3679# OwnWaterloo

应该遵守习俗
除非有充分的理由
因为习俗的形成本身自有其理由
标新立异也需要理由

至于谭的理由，我不记得他的书有include .c了。即使有，我也不关心他这本书怎样。。。

我关心的是：
1. 你们凭什么轮番指责村夫？就include .c而已，多大回事？
2. 那村夫的理由够不够？仅通过ISO C的标准机制而非扩展就可以解决问题。 仅仅遵守C语言还不够，非得按你们的行为准则行事才行？
3. 我还是没能理解你在对include .c这一问题上，与对待其他问题上的态度反差之大的原因。 这事我在另一贴中再细说。

OwnWaterloo

pmerofc 发表于 2012-08-01 09:06
这里又引申出另一个问题
就是
如果只能#include *.c
那么是否应该换一种扩展名为好
我是支持换个扩展名的

村夫说了，一般编辑器会对.c按C语法高亮。 .h一般也会，但你接受这扩展名么？

退一步，不说那些不能配置扩展名与语法映射的编辑器。
假设各种编辑器都可以配置，不能配置的就应该被淘汰。
但配置本身就是代价。

记得很久以前，我就为这个事折腾过。
VS08还是VS10，为了让tr1(C++新增的没有扩展名的若干头文件）能高亮。

OwnWaterloo

把前面说好的一个问题先说了，免得忘了。
就是不理解你为什么在对此问题上的态度差别这么大。

对一些普通C程序员都习以为常的，但又超出ISO C之外的概念：
1. 栈(automatic 所用的)
2. 堆(dynamic 所用的)
3. .(r)data .bss(static 所用的)
4. itoa,stricmp(ISO C标准库之外，但又相近的内容)
……

具体的态度我也不记得了。大致是抵制的，视而不见 —— ISO C没有这些概念，所以这些概念不存在。
总之，与对visibility的态度完全是相反的 —— ISO C没有这些概念，但如果编译器提供了，就用。

这是为什么？因为谭提出了include .c，所以要反include .c，所以不惜连编译器扩展都用？

OwnWaterloo

pmerofc 发表于 2012-08-01 09:38
回复 3679# OwnWaterloo

但是对#include *.c
我始终觉得不自然
因为这些*.c和别的*.c不同
会使我产生一丝凌乱感
所以如果编译器提供了其他手段不用#include *.c
显然我会赞同其他方案
因为这些手段很可能就是为了不#include *.c而专门设计的

DEF与visibility可不是为了不include .c而设计的。


或者换种说法。我不认为它们是为了不include .c设计的。 你认为也许是。 那到底是不是？ 这问题能辨出个让双方都信服的是非黑白么？
同理。你认为include .c不应该像村夫那样用， 让你感到不自然、凌乱。 但村夫认为他用得合理。 到底是否合理？ 这问题又能辨出个让双方都信服的是非黑白？
机制(DEF,visibility,include)被设计出来，产生了一种超出预期的、但又没有违法任何条款的使用方式 —— 这事你也在做。

这种根本就没有决定性定义的问题，纠缠就是蛋疼。

OwnWaterloo

这是很常见的"禁用goto"支持派的做法 —— 将代码写得比那些谨慎使用goto的人写出的更乱。然后说goto是应该禁用的。
NO，禁用的应该是这些人自己。

类似下面这些东西你举再多都没用，已经偏题了。

pmerofc 发表于 2012-08-01 08:59
应该遵守习俗
除非有充分的理由
因为习俗的形成本身自有其理由
标新立异也需要理由

早上我编译了一个程序
x.h:
int main(void)

main.c:
#include "x.h"
{
  return 0;
}

完全没有违背C标准

但不违背C标准与理性地写程序不是一回事

#include 确实不是语言的一部分
而是一种普遍的、组织代码的手段
如何应用#include
离不开组织代码的指导思想

村夫有将代码写成这样？

pmerofc 发表于 2012-08-01 10:05
早上看了一段代码
do{……
……
……
do{
……
if(…)
{
}
}while(…);
do{
……
}
……
}while(…);

与正确性无关

无关正确性的选择
往往也需要理性的支撑

村夫又有将代码写成这样？

pmerofc 发表于 2012-08-01 09:55
比如 a+=a-=a*a
标准和编译器都没有承诺
所以不应该相信这个结果，哪怕它表面上迎合了我们

include与static是不是ISO C提供的承诺？难道还不如那些编译器扩展可靠？

OwnWaterloo

pmerofc 发表于 2012-08-01 09:25
这些观点都是似是而非的歪曲
实际上这些说法（原来的）都很细腻
一不小心就被歪曲了

我知道原始说法没有这么激进，而是被一些喜欢将自己禁锢在条条框框里才有安全感的人讹传的。
我举这些的意思是：你们（在批评村夫这一事上）与这些人一样激进。

pmerofc 发表于 2012-08-01 09:25
use your brain, always。
这绝对没问题
但是谭的代码并非如此(在#include *.c的时候)
村夫那个则不同
蔡那个也不同
都是use brain

前面说了，谭的事我无能为力。我不愿将自己的时间花在无可救药的事上。
那既然村夫不同，为什么会被一直纠缠？

pmerofc 发表于 2012-08-01 09:25
这里又引出另一个问题
如果能不use brain也能写好代码显然更好
良好的习惯可以让人在不use brain或少use brain的情况下把代码写正确
毕竟CODER写代码时需要考虑的事情很多
不应该总在鸡毛蒜皮上操心
写switch应（不是须）接break，哪怕是最后一个标号
我认为就是这种情况
如果每次都想想该不该break
考虑其他重要问题的时间就变少了
就很可能纠结于细节而无法自拔

如果每次都想想，习惯了后想这回事根本连自己都意识不到。
如果希望依靠这种良好的习俗写好代码，因为缺乏这种锻炼，才会让自己感到没有安全感，而更依赖这些习俗。

就像 if (p==q) ，心里想到的等测试，手里下意识的就敲出两个等号。根本就没机会反应/考虑/或忘记这里应该是=还是==。
不将标号与缩进这种很直观的意象当作block，而是没看到break就一直往下读。
static就有初值，automatic就初值不定 —— 这些东西怎么可能忘得掉？
这也是种习惯。

我是很难想象 if (0==p), swtich每个标号都break, 定义时总是附带初始化（包括数组的各种低效甚至错误的初始化方式）能有多大作为。
需要这些习俗才能写代码的程序员， 我反到是觉得他们自己没有安全感， 我也对他们感到没有安全感。

同样很难理解倾向于了解其他人定下的习俗而不是去了解语言本身（那些习俗的源头）。
那些习俗本身难道就不是细节？ 沉迷/纠结它们就不是沉迷与纠结？ 就不会无法自拔？ 就不会影响考虑重要问题的时间？
而且很可悲的是，这些习俗往往变个环境(team,boss...)就变了。 而了解语言本身才是不变应万变的。

OwnWaterloo

pmerofc 发表于 2012-08-01 09:06
没问题
但是存在一种可能
村夫的编译器不支持蔡的编译器上的功能
因此他当时只能想到#include *.c
一个人使用的工具必然影响他的思维

你是说，村夫连GCC都没用过、连visibility都不知道？所以才只能想出这种下三滥手段？我只是猜测村夫不可能菜到这种地步，不过没法证明了。
我怎么觉得反而是村夫用过比蔡更多的编译器，才导致他要去想一种编译器无关的手段？对蔡用过的、村夫用过的、甚至没用过的、将来出现的编译器都能凑效的手段。

确实是工具影响思维。