第一章 起步，干净的代码

刚完成了一个Android的项目，由于开发周期的问题，代码的确是写的非常杂乱，回首整理代码，都不堪入目。

目前又要着手一个IOS的项目，以后不论开发周期是否紧张，养成良好的习惯对开发者来说受益匪浅。

（以下摘自网络，仅供参考。）

 

1，命名，命名就是注释。
用驼峰法，比如 doSomething
类名：头字母大写
方法名：头字母小写
局部的子方法里允许 int i这种，但是常用的方法中，必须写成 int xxxIndex
临时变量命名        tmpXXX

然后，如果发现命名不对，或者后来发觉其他命名方式更好，用项目的命名修改工具修改

 

2，方法（函数）
方法名一定要能做注释，如果必要，加方法注释，如果IDE允许，一定是那种别人在引用你的方法的时候了可以直接看到的注释（这里解释一下，记得java中可以通过在函数前面加/**xxx*/加注释，这样当方法提示的时候，会自带这种注释提示，xcode,mono都有类型的功能）
一个方法只做一件事，尽可能这样，如果一个方法做了n多事，拆分。
一个方法不允许出现大于100行的情况，正常50行以内(这个要求已经很宽泛了)，如果大于100，拆分，没有时间，自己找时间拆分
方法内，相关的代码写在一起，不要有空行，相关度小的，留一个空行
良好的缩进，这里不做强制要求，采用两种缩进中的一种，根据个人习惯
能私有的方法一定要私有，不要让大家看到(OC是通过类别来实现的)
多用代码组的工具，并加入清晰的注释
（Xcode中，是通过 #define mark xxx注释 来让方法分组的）
（Unity3d中的mono工具是 #region xxx注释 #endregion）

 

3注释
如果命名能做注释，就不要注释
如果不得不做注释，尽量是那种别人调用的时候可以直接看到的注释
类的每一个和其他类有关联的成员，都写上注释
如果一个注释已经过时了，删掉或修改掉

//以上1,2,3 针对团队所有人

 

4，关于框架
每一个类尽量只做一件事或一类事
少用继承，多用组合
类内高内聚，类之间低耦合
UI和数据分开，如果有足够的时间

 

5，重构
唯一不变的就是变化，游戏开发尤其如此，适当的时候，提出重构
频繁，多次，自己抽时间做重构

 

6，关于合作
对每一个人做的东西，让他有一个系统的概念，不要今天做这一块，明天做那一块
合作尤其要求代码的可读性，一定要让自己的代码别人可读
如果你是一个程序员，做好自己的代码，如果你负责很多人，让每一个人写好自己的代码，然后，你写好清晰的接口
和策划谈需求时尽量搞清楚，开始做的时候去白班上画图，让开发者都清晰的知道设计思路和每个人做什么
诱导为主，拒绝依赖性的问问题，这个态度一开始就要让问问题的人知道

 

7，关于warning

xcode里面开发程序的时候，自己写的代码，0 warning，第三方的，warning处理到 个位数，或者全部处理掉

很多时候，需求的变动和时间的压力会让一个开始很干净的工程慢慢变得一塌糊涂，没有捷径，除了细节上的注意，就是一遍又一遍的重构。个人认为项目中绝大多数时间是在维护代码，而不是写新代码，既然要维护，能够一眼看清的代码是最好的，而团队合作又会把代码的可读性问题无限制的放大，尤其是遇到一些很聪明常常自作主见和一些偷懒的人的时候。基本的规范是一定要遵守的，而这个习惯也会有助于程序员越走越远。每一次重构都是一次脱胎换骨的涅槃，其中的痛，只有身在其中的人知道，很多时候都是自己在下班时间做的。

 

写在最后，其实这些都是非常普通的，每个程序员都应该牢记的，记得之前即使在赶asp.net的项目，但是那些代码依然编写的很标准，可读性很高，可能还是由于写的多了每次都更随习惯了。所以对于一个新的开发语种，也要把之前的习惯带过来。

转载于:https://www.cnblogs.com/Castiel/archive/2012/08/13/2635894.html