为什么有的程序看着不舒服

首先必须要说的几点,我不保证这篇文章中的都是正确的,这篇文章也不能保证给你正确的解决方法。换言之,这是一篇牢骚贴。

我本人这些年一直从事手机游戏的移植方面。绝大部分是将java代码移植到C/C++平台的。看到过各种各样的代码,有写的非常漂亮的,也有非常差的,看到好的代码,有一种如鱼得水的感觉,差的代码,犹如如鲠在喉,要命的是,还必须忍受着强迫自己看完,那种感觉,简直无法表达。我一直想要找一个可以解决的办法,然后弄个什么写好代码的方法之类的,最后还是放弃了,但挑刺总比拨乱反正要好的多,所以就有了这篇。

1、代码的格式化问题。代码最好有一个统一的格式,不管是gnu风格还是k&r风格或者你自己创造的风格,最好能统一并保持一直,不能在一个文件中使用几个风格。写代码的风格并不能保证你的代码编译后的质量好与坏,但可以让看代码的人感到舒心,且觉得你这个人还是比较有那么些规矩或者原则的。谁也不愿意看到看上去像飞机或者其他什么东西的代码,而如果你弄出这样的代码,并不能提升你在程序方面的水平,只能觉得你比较无聊,只有无聊的人才能写出这样的IOCCC。统一的格式化还有一个好处就是可以快速的融入到团队中,如果你技术很好,而不注意这一点,其他人则跟着你很累,如果你技术不好,其他人觉得和你配合很累。所以,赶快养成好习惯吧。(我现在拿到别人代码的首先一件事情是格式化。)

2、注释问题。注释并不会被编译到最终程序中去,可以说,有无注释完全对你程序的执行并不重要。但如果接手你项目的人看到你的代码的话,则可能一头雾水。他/她完全无法知道你的思想,你所有的思想都融入到程序中了,但他/她则没有那么多的时间去一一仔细辨别,这时候好的注释就起到作用了。准确的注释可以让他/她节省90%的时间。所以,如果你有浪费别人生命的喜好的话,删除掉注释吧。

3、文件长短的问题。这有关系吗?现在的项目越来越大了,代码越来越多了,A写的代码,B写的代码,C写的代码,最后越来越多的代码扔到了一个文件中,起个名字叫fun1,fun2之类的。虽然现在辅助看代码的工具不少,功能也越来越强大,但你考虑过看你代码的人,用鼠标回滚了N次,就为了看你的声明或者注释或者实现之类的感觉吗?不要尝试在一个桶里装下所有东西,不过我家倒是有一个这样的桶:垃圾桶。

4、文件的组织形式。我个人并不喜欢把文件扔到很深的目录中,不幸的是,java很喜欢这样的目录,什么com.java.什么的,更不幸的是,android也延续了这一作风。于是,我不得不一次次的进入很深的目录中去,就为了看下某个文件。不过,想比java更不幸的是,有些人的代码文件的组织形式更加令人风中凌乱。我曾经看到一个项目中的目录中有source,src,include,若干.java,然后我就完全莫名奇妙了,如果source中的代码是原始代码的话,那么src中是什么,外面的那些.java是干什么用的,include中包含的仅仅是些宏定义或声明之类的还是会包含很多的java实现代码。然后不断的询问才理清楚所有的关系。

5、函数的长度。有的人喜欢写长长长长的函数,几乎将所有的内容都塞到一个函数中,在我刚学程序的时候,也是如此。最后实在觉得每次滚鼠标太累了,记住所有的事情太累了,只好作罢。我不喜欢看一个函数超过两屏,我更喜欢建议看看linux内核的编码规范。不过,我看到的很多代码倒是喜欢这样做。

6、版本管理。不管是svn也好,cvs也好,git也好,我都建议别人有一个版本管理,并经常性的备份。几乎所有的版本管理都支持差异比较,从代码的比较中,不仅仅可以感受到一种成就(那种项目从无到有的感觉),还能体现出想法或者思路的更改。如果你仅仅用来做一个初始化版本管理,然后只在最后完成之后提交一次的话。这些话算我没说过。

7、编译语言的差异。其实这个不是谁对谁错的事情,你必须尊重并理解这种差异,尤其像我这样以移植项目为主的。不同编译语言的移植项目一般要求至少精通两种语言(奇怪的是,有些人总认为这些很容易),不仅仅要熟悉各个语言的风格,还要了解其优缺点,这非常不容易。往往最初学习的那个语言对人的影响力比较大(例如我学的汉语),我虽然经常的写C++代码,但其实还是比较喜欢看C代码(我正式学的第一个语言)的。我很擅长汇编(这是我很认真的学习了的语言),但在项目中还是仅可能的避免使用,即使使用也是尽可能的简短。在我眼里,lisp是苦涩的,C是简洁的,汇编是高效的,C++是冗繁的,java几乎是个累赘。不管你同意与否,这只是我个人的观点,但我无法说他们谁好与不好,只是在不同的场合下,都有各自的优缺点。

8、我还没有想到的,其实还有什么函数命名之类的,鉴于我看到的代码越来越少了,这些就不说了。

发布者

rix

如果连自己都不爱自己,哪还有谁来爱你