首先必须要说的几点，我不保证这篇文章中的都是正确的，这篇文章也不能保证给你正确的解决方法。换言之，这是一篇牢骚贴。
我本人这些年一直从事手机游戏的移植方面。绝大部分是将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、我还没有想到的，其实还有什么函数命名之类的，鉴于我看到的代码越来越少了，这些就不说了。