适用于< 80 char线的C风格指南提示

时间:2011-02-05 10:51:33

标签: c coding-style

我找不到很多推荐/风格指南 提到如何在C中分割线条的C 每行少于80个字符。

关于我唯一能找到的是PEP 7, Python主要版本的样式指南 (CPython)。

是否存在综合C风格指南的链接 其中包括包装建议?

或者失败了,至少有一些好的个人建议 在这件事上?

P.S。:你怎么处理really_long_variable_names_that_go_on_forever (除了缩短)?你把它们放在左边缘还是让它溢出来?

4 个答案:

答案 0 :(得分:5)

这是关于(linux)内核编码风格的Linus'original article。该文件可能已经发展,因为它是source distribution的一部分。

答案 1 :(得分:3)

你可以看看GNU Coding Standards,它涵盖的不仅仅是编码风格,但仍然非常有趣。

答案 2 :(得分:1)

每行“规则”中的80个字符已过时。

http://richarddingwall.name/2008/05/31/is-the-80-character-line-limit-still-relevant/

http://en.wikipedia.org/wiki/Characters_per_line

http://news.ycombinator.com/item?id=180949

我们不再使用punched cards了。我们拥有巨大的显示器,分辨率很高,只会随着时间的推移而变大(显然手持设备,平板电脑和上网本是现代计算的重要组成部分,但我认为我们大多数人都在台式机和笔记本电脑上编码,甚至笔记本电脑都有这些天大显示。)

以下是我认为应该考虑的规则:

  

一行代码做了一件事。

     

一行代码写为一行代码

换句话说,让每一行尽可能简单,不要将一个逻辑行分成几个物理行。规则的第一部分有助于确保合理的简洁性,以便符合第二部分不会造成负担。

有些人认为某些语言会鼓励复杂的“单行”。 Perl是一种被一些人认为是“一次编写,从不读”的语言的例子,但你知道吗?如果你不编写混淆的Perl,如果相反你每行做一件事,Perl代码就像其他任何东西一样可管理......好吧,也许不是APL;)

除了复杂的单行之外,我认为符合某些人为角色限制的另一个缺点是缩短标识符以符合规则。没有缩写和首字母缩略词的描述性标识符通常比缩短的替代标识符更清晰。清除标识符使我们更接近literate programming

对于保持80或其他值,字符限制,我听过的最好的“现代”论证可能是代码的“并排”比较。并排比较对于比较同一源文件的不同版本非常有用,如source code version control system merge operations中所示。就个人而言,我注意到如果我遵守我建议的规则,我的大部分代码都足够短,当两个源文件(甚至三个,三向合并)是完整的时候,它们是完整的。在现代展示上并排观看。当然,其中一些超出了视口。在这种情况下,如果我需要查看更多,我只需滚动一点。此外,现代比较工具可以很容易地告诉您哪些线条不同,因此您知道应该看哪些线条。如果你的工具告诉你没有理由滚动,那么没有理由滚动。

答案 3 :(得分:0)

我认为每行80个字符的旧建议来自显示器为80x25的时间,现在128个或更多应该没问题。