如何养成良好的Linux编码风格

Linux操作系统是一个开源的操作系统,为此你在Linux系统上开发的一个工具软件,包括源代码,可能其他系统管理员也需要用到。为此在编写代码的时候,就需要遵守一定的规则。这不仅是为了方便他人的阅读,也是为了以后自己的维护与升级考虑。具体的来说,笔者认为Linux系统管理员要养成下面的一些好的编码风格。

一、 合理防治函数开头的左花括号。

根据大部分系统管理员认可的编码风格,往往将函数开头的左括号放到代码页的最左边。要避免将其他的括号(包括左花括号、左括号或者左方括号)放到最左边。这主要是为了便于阅读。因为函数的主体内容往往是有一对花括号括起来的。如果在代码页的最左边只有代表函数的花括号,那么就可以一目了然的看到函数的主体。为此这是提高代码阅读性的一个很好的手段。

需要注意的是,这可能跟其他语言的编程风格有所差异。如在Java语言或者C语言平台上,往往将函数主体开头的花括号放在函数的后面。如在main函数后面会直接使用{这个左花括号。不过这不利于程序的阅读,不利于Linux系统管理员找到函数的主体代码。为此如果有其他编程语言使用经验的系统管理员,最好能够改变这种书写习惯。笔者建议,系统管理员还是要将这个花括号放在最左边,并保证在整个代码中,最左边出现的花括号都是代码函数主体的花括号。

二、 每个函数开头最好都有一个简短的代表功能的说明。

在Linux的功能代码中,其各个功能也都是一个个函数或者程序构成的。也就是说,在一个代码文件中,可能会有很多个函数构成。那么这些函数主要用来实现什么功能呢?如果不做任何说明的话,那么只有看完函数的全部代码之后才能够了解这个信息。这对于他人阅读源代码会造成比较大的障碍。而且,时间久了之后,可能连系统管理员自己都不知道这个函数时用来实现什么功能的。这对于其后续维护与升级显然是不利的。为此笔者建议各位系统管理员,无论是为自己还是为他人,最好在每个函数或者程序的开头都写上一小段注释。好记性不如烂笔头,这对于提高代码的易读性。另外需要说明的是,由于Linux系统可能对中文的支持并不是很好,为此在写这个注释的时候,最好采用英文书写。因为在一些对中文支持并不是很好的系统中,这个中文会显示为乱码,此时就起不到应有的作用了。如果不懂英文的话,那么可能只有使用拼音了。当然这只是笑话。一般Linux系统工程师对于英文需要一定的了解。因为Linux操作系统中的帮助文档都是英文写的。所以这个英文的语言关也是系统管理员必须要解决的关口。

另外在对函数进行说明时,最好还需要著名这个函数需要用户传入什么参数,会返回什么样的结果。以及参数、结果的个数等等。这对于代码的编译与维护非常有帮助。而且项目团队中的其他成员如果要引用你这个函数的话,那么不需要查看函数的具体代码。而只需要查看一些这个注释,就可以知道需要传递进去哪些参数。这也是提高项目合作效率的一个手段。

三、 If语句使用要规范。

在Linux系统中编写代码时,IF语句是使用的最多的结构之一。这个if语句主要用来实现一些逻辑的判断。虽然这个语句本身比较简单,但是在使用这个语句时,最好也能够遵守一些规则。虽然这些规则主要是从易读性的角度去考虑的,但是对于编写一个准确的IF结构语句也有所帮助。

如根据Linux系统的编程习惯,最好不要在IF的条件中进行赋值。IF语句需要根据某个条件来进行判断该采取什么样的操作。在这个条件中,根据语法是可以在这个条件中对变量进行赋值的。但是这不符合Linux系统下的编程风格。笔者建议,最好在IF结构外部对变量进行赋值,然后再在条件中直接使用这个变量。这更易于控制IF结构。另外,如果在IF语句中使用嵌套的话,可以使用花括号将嵌套的IF ELSE语句括起来,以利于发现这个嵌套语句。在其他应用程序编写过程中,是使用缩进的方式来凸现IF嵌套结构的。但是Linux系统管理员更加喜欢使用花括号。虽然这两个没有实质上的区别,但是笔者还是建议采用花括号。因为这是一个Linux操作系统业内普遍认可的一个编码风格。

时间: 2024-12-30 22:55:45

如何养成良好的Linux编码风格的相关文章

《Linux 高级程序设计(第三版)》——1.4 Linux下编码风格

1.4 Linux下编码风格 Linux 高级程序设计(第三版) 下面为读者列出GNU编码规范和Linux内核编码规范示例. 1.4.1 GNU编码规范 下面是GNU emacs中的一段代码. /* Interface from Emacs to terminfo. Copyright (C) 1985, 1986 Free Software Foundation, Inc. This file is part of GNU Emacs. GNU Emacs is free software;

Linux操作系统内核编码风格

这篇简短的文章描述了Linux内核首选的编码风格.编码风格是很个人化的东西,我不会把自己的观点强加给任何人.但是,Linux内核的代码毕竟是我必须有能力维护的,因此我宁愿它的编码风格是我喜欢的.请至少考虑一下这一点. 首先,我建议打印一份<GNU编码标准>,不要阅读它.烧掉它,它不过是象征性的姿态.然后,请看: 第 1 章: 缩进 Tabs(制表符)是8个字符的大小,因此缩进也应该是8个字符的大小.有些叛逆主张试图把缩进变成4个(甚至是2个!)字符的长度,这就好象试图把PI (案,圆周率)定义

谈谈编码风格与编码规范

作者:玉伯   引子 上一篇文章提到 「习惯与变化」,收到了比较有意思的一些反馈: 我很好奇,如果你的团队中有人以"习惯"的名义打破编码规范会怎样?于我而言,不写四直接写五就是这种感觉,这并不是习惯,而是规范. 还有一封很长的邮件,截取一二: 玉伯哥,我经常会为一些事情纠结,比如创建文件夹的时候会想是首字母大写好看呢还是全小写来保持统一呢(Movie,movie,mytest,MyTest),当写程序注释的时候我会想是写 // this function proves that- 好呢

《Python高手之路(第3版)》——1.4 编码风格与自动检查

1.4 编码风格与自动检查 没错,编码风格是一个不太讨巧的话题,不过这里仍然要聊一下. Python具有其他语言少有的绝佳质量:使用缩进来定义代码块.乍一看,似乎它解决了一个由来已久的"往哪里放大括号?"的问题,然而,它又带来了"如何缩进?"这个新问题. 而Python社区则利用他们的无穷智慧,提出了编写Python代码的PEP 8(http://www. python.org/dev/peps/pep-0008/)标准.这些规范可以归纳成下面的内容. 每个缩进层级

JavaScript编码风格指南(中文版)_javascript技巧

前言: 程序语言的编码风格对于一个长期维护的软件非常重要,特别是在团队协作中.如果一个团队使用统一规范的编码分风格,可以提高团队的协作水平和工作效率.编程风格指南的核心是基本的格式化规则,这些规则决定了如何编写高水准的代码.本指南来自于<编写可维护的JavaScript>这本书,基于"Java语言编码规范"和Crockford的JavaScript编程规范,还有Nicbolas的一些个人经验和喜好.写作本文旨在加深自己印象,也为了更多人的了解到JS编码风格,提高自己的编码质

《Python高手之路》——1.4 编码风格与自动检查

1.4 编码风格与自动检查 没错,编码风格是一个不太讨巧的话题,不过这里仍然要聊一下. Python具有其他语言少有的绝佳质量2:使用缩进来定义代码块.乍一看,似乎它解决了一个由来已久的"往哪里放大括号?"的问题,然而,它又带来了"如何缩进?"这个新问题. 而Python社区则利用他们的无穷智慧,提出了编写Python代码的PEP 8(http://www.python.org/dev/peps/pep-0008/ )标准.这些规范可以归纳成下面的内容. 每个缩进层

Nim编码风格

介绍 Nim语言不限制开发人员使用哪种具体的编码风格, 但为了社区的发展,在编写一些标准库的时候还是应该遵从统一的编码风格 这篇文章会列出一系列的编码风格准则,供大家参考.   但值得注意的是,有很多例外场景会与这些准则相悖, 而且,nim语言非常灵活,在一些特定上下文中,这些编码风格准则也不适用. 跟python相似,python的编码风格在不断演化.改变, nim语言也是这样,随着时间的推移,这个编码风格准则也会改变.   在编写nim的基础类库.编译器.官方工具的时候, 强制要求遵从这些编

谈谈 Linux 内核驱动的编码风格

最近在向Linux内核提交一些驱动程序,在提交的过程中,发现自己的代码离Linux内核的coding style要求还是差很多.当初自己对内核文档里的CodingStyle一文只是粗略的浏览,真正写代码的时候在很多细节上会照顾不周.不过, 在不遵守规则的程序员队 伍里,我并不是孤独的.如果去看drivers/staging下的代码,就会发现很多驱动程序都没有严格遵守内核的coding style,而且在很多驱动程序的TODO文件里,都会把"checkpatch.pl fixes"作为自

谈谈Linux内核驱动的编码风格

最近在向Linux内核提交一些驱动程序,在提交的过程中,发现自己的代码离Linux内核的coding style要求还是差很多.当初自己对内核文档里的CodingStyle一文只是粗略的浏览,真正写代码的时候在很多细节上会照顾不周.不过, 在不遵守规则的程序员队 伍里,我并不是孤独的.如果去看drivers/staging下的代码,就会发现很多驱动程序都没有严格遵守内核的coding style,而且在很多驱动程序的TODO文件里,都会把"checkpatch.pl fixes"作为自