代码风格:关于左花括号位置的研究

C/C++中左花括号位置的争论由来已久,本文分析了两种写法产生的历史缘由,并提出现在我们应该采用的写法和理由。

下面是引起争论的两种风格:

K&R风格:

if (a > 100) {
    //do somthing…
}

(注:1978年贝尔实验室正式发表了C语言。同时由B.W.Kernighan和D.M.Ritchie (K&R)合著了著名的《The C Programming Language》一书。书中推荐了一套代码编写标准,有人称之为《K&R》标准。)

微软风格:

if (a > 100)
{
    //do somthing…
}

网上的朋友有些支持K&R, 因为是它更经典,有的支持微软,因为它更现代,有的认为只是一种习惯,哪种都可以,无须纠结。但我还是存在一个疑问:从观感来看,微软的风格显然更悦目,更对称,为什么K&R要推荐这种看上去有些怪异的风格?除了习惯之外,我想不出这样做的哪怕是一个好处。

最近忽然想到,这可能和早期显示器的分辨率有关:以1981年IBM推出的第一台计算机彩色显示器标准CGA为例,它的最高分辨率为640*200。竖向分辨率居然只有200, 现在一台普通的22寸显示器的竖向分辨率是1080,大约是它的5倍!在这种情况下,屏幕空间就金贵了,K&R的风格可以省一行的空间,否则一屏根本显示不了几行代码。有时候令人非常困惑的问题,答案往往意想不到的简单,不是吗?

明白了这一点,争论就可以结束了:今天当然是用微软风格,因为K&R风格的理由已经不存在了,今天你能找到的再旧显示器分辨率恐怕也不会低于1024*768吧?所以还是要知其所以然,不能死记硬背大牛的教条。

时间: 2024-10-13 09:58:26

代码风格:关于左花括号位置的研究的相关文章

PSR代码风格指南

代码风格指南 本手册是基础代码规范(PSR-1)的继承和扩展. 为了尽可能的提升阅读其他人代码时的效率,下面例举了一系列的通用规则,特别是有关于PHP代码风格的. 各个成员项目间的共性组成了这组代码规范.当开发者们在多个项目中合作时,本指南将会成为所有这些项目中共用的一组代码规范. 因此,本指南的益处不在于这些规则本身,而在于在所有项目中共用这些规则. RFC 2119中的必须(MUST),不可(MUST NOT),建议(SHOULD),不建议(SHOULD NOT),可以/可能(MAY)等关键

PHP团队 编码规范 & 代码风格规范

一.基本约定 1.源文件 (1).纯PHP代码源文件只使用 <?php 标签,省略关闭标签 ?> : (2).源文件中PHP代码的编码格式必须是无BOM的UTF-8格式: (3).使用 Unix LF(换行符)作为行结束符: (4).一个源文件只做一种类型的声明,即,这个文件专门用来声明Class, 那个文件专门用来设置配置信息,别混在一起写: 2.缩进 使用Tab键来缩进,每个Tab键长度设置为4个空格: 3.行 一行推荐的是最多写120个字符,多于这个字符就应该换行了,一般的编辑器是可以设

PHP PSR-2 代码风格规范 (中文版)

代码风格规范 本篇规范是 PSR-1 基本代码规范的继承与扩展. 本规范希望通过制定一系列规范化PHP代码的规则,以减少在浏览不同作者的代码时,因代码风格的不同而造成不便. 当多名程序员在多个项目中合作时,就需要一个共同的编码规范,而本文中的风格规范源自于多个不同项目代码风格的共同特性,因此,本规范的价值在于我们都遵循这个编码风格,而不是在于它本身. 关键词 "必须"("MUST")."一定不可/一定不能"("MUST NOT"

python代码风格指南:pep8 中文翻译

摘要 本文给出主Python版本标准库的编码约定.CPython的C代码风格参见?PEP7.本文和?PEP 257 文档字符串标准改编自Guido最初的<Python Style Guide>, 并增加了Barry的?GNU Mailman Coding Style Guide的部分内容.本文会随着语言改变等而改变.许多项目都有自己的编码风格指南,冲突时自己的指南为准. 本文给出主Python版本标准库的编码约定.CPython的C代码风格参见PEP7. 本文和PEP 257 文档字符串标准改

PSR-2 代码风格规范

这篇规范是PSR-1(基本代码规范)的扩展和继承. 本规通过制定一系列规范化PHP代码的规则,以减少在浏览不同作者的代码时,因代码风格的不同而造成不便. 这个风格规范是从各种各样的项目的共性中延伸出来的.当多名程序员在多个项目中合作时,它有助于有一套准则,在所有的项目中使用. 因此,本指南的好处不是在规则本身,而是在这些规则的共享. 关键词 "必须"("MUST")."一定不可/一定不能"("MUST NOT")."

[转] Linux内核代码风格 CodingStyle [CH]

from:http://blog.csdn.net/jiang_dlut/article/details/8163731 中文版维护者: 张乐 Zhang Le <[email protected]> 中文版翻译者: 张乐 Zhang Le <[email protected]> 中文版校译者: 王聪 Wang Cong <[email protected]>                wheelz <[email protected]>        

Linux内核代码风格

这是一个简短的文档,描述了linux内核的首选代码风格.代码风格是因人而异的,而且我 不愿意把我的观点强加给任何人,不过这里所讲述的是我必须要维护的代码所遵守的风格, 并且我也希望绝大多数其他代码也能遵守这个风格.请在写代码时至少考虑一下本文所述的 风格. 首先,我建议你打印一份GNU代码规范,然后不要读它.烧了它,这是一个具有重大象征性 意义的动作. 不管怎样,现在我们开始: 第一章:缩进 制表符是8个字符,所以缩进也是8个字符.有些异端运动试图将缩进变为4(乃至2)个字符 深,这几乎相当于尝

Linux内核编程规范与代码风格

source: https://www.kernel.org/doc/html/latest/process/coding-style.html translated by trav, [email protected] 这是一篇阐述Linux内核编程代码风格的文档,译者以学习为目的进行翻译. 1 缩进 Tab的宽度是八个字符,因此缩进的宽度也是八个字符.有些异教徒想让缩进变成四个字符,甚至是两个字符的宽度,这些人和那些把 PI 定义为 3 的人是一个路子的. 注意:缩进的全部意义在于清晰地定义

设置自己Eclipse代码风格(内部)

经过这几次的代码提交,发现很多人的代码风格不够规范.个人认为很有必要强制性规定一下代码的规范. 整体来说,有三种代码风格,其中两种类似于这样的: public void function(){ //function body } 很明显,对于多层代码块嵌套的情况,代码会变得难以阅读. 程序员要记住,代码写出来是给别人读的,绝对绝对要避免只写(write-only)代码.一种好的代码风格必然会善用两点:缩进(indent)和适当的换行. 我的代码风格是这样的: public void functi