一个文件（或函数）代码很长是严重的问题吗？

[virushuo]

从 @newblue 给 @livid 的意见 http://www.v2ex.com/t/10859 而起，觉得这问题可以讨论。

我认为“代码过长是不好的变成习惯”的说法已经过时了。在过去编辑器不够发达，语言能力不够强的时候，一个函数中过长的代码确实难以维护和调试。但现在已经有很多足够好的编辑器和IDE，并不会感觉到麻烦。

比如Xcode支持的 #pragma mark ，就算一个.m文件再长，只要有打这种mark的良好习惯，都会容易组织代码，维护并不困难。

调试也一样，如果直接用gdb调试，过长的函数也很麻烦。但现在有了更多的静态和动态分析方法，很多时候不需要再用gdb一行一行的调代码了。（动态语言就更没这麻烦了）

而文件太多，要在文件之间来回跳来跳去，反而不如 #pragma mark 这种标记容易使用。

所以我认为以代码长已经可以看作一种编程风格，而不是一种坏习惯。当然代码逻辑混乱，另当别论。

大家的看法呢？

[virushuo]

@Platinum 是我问的。我觉得一些说法确实过时了。比如我现在就宁可在一个.m里面写很多，也不愿意拆开，因为xcode足够方便，处理一个比处理一堆文件方便多了。我的本意是，所谓的编程习惯是不是应该根据实际情况有一些变化，而不能当作判断的永恒标准。

[apoclast]

个人不太喜欢这样, 不过偶尔看一些著名开源项目代码的时候, 发现这样情况也蛮普遍的, 所以不想多说什么了

[virushuo]

另外说一个函数太长不好的人估计是没怎么看过大的开源项目，比如你去看看lucene/mapreduce，长的吓死人。

[virushuo]

@Platinum 而事实上，编译器也是经常出错的，写内核的发现结果不对先去debug gcc是很常见的啊。

[Kymair]

@virushuo 我认同编程习惯确实应该与时俱进。不过似乎在这个问题上，感觉似乎是相反的方向:D 比如以前都说C函数调用开销大，得多inline。现在机器性能越来越强大，IDE和Editor的功能越来越丰富，似乎是向切分成更多文件/函数的方向发展。

[phpuser]

系统里面C代码单文件超30K行，单函数超3K行，全量编译超过4小时的家伙，无语飘过。。。。lolz...

[phpuser]

好在VIM强大，要是我也用UE之类的，估计早崩溃了。看代码、找错误真是非常痛苦的事情。mark多了自己都找不到哪个mark是哪个了。不过在一个体系内，个人的力量是非常渺小的。。何况有些还是世纪性的遗留问题。。