注意代码的规范和可读性

命名


N1:采用描述性名称.命名要具备描述性.
N2:名称应与抽象层级相符.
    public interface Modem {
      boolean dial(String phoneNumber);//应修改为 boolean connect(String phoneNumber);
      boolean disconnect();
      boolean send(char c);
      char recv();
      String getConnectedPhoneNumber();
    }
N3:尽可能使用标准命名法
N4:无歧义的名称.
N5:为较大作用范围选用较长名称.名称的长度应与作用范围的广泛度相关.
N6:避免编码. 不应该在名称中包括类型或者作用范围信息.
N7:名称应说明副作用. 应该说明函数,变量或类的一切信息.


注释


C1:不恰当的信息.
C2:废弃的注释. 过时,无关或者不正确的注释就是废弃的注释.
C3:冗余注释. 如果注释描述的是你某种充分自我描述了的东西,那么注释就是多余的.
C4:糟糕的注释.注释要精准,简洁
C5:注释掉的代码. 全部删掉!


环境


E1: 代码BUILD需要多少部.标准是签出代码,就可用单个指令构建它.
   svn get mySystem
   cd mySystem
   ant all
E2: 单个指令可运行全部的单元测试.


函数


F1: 过多的参数. 函数的参数量应该少. 没参数最好,一个次之,依次类推.
F2: 少用输出参数
F3: 标示参数.
F4: 不被调用的函数. 直接删除,保留代码的整洁.


一般性问题


G1: 一个源文件中存在多种语言. 理想的源文件包括且只包含一种语言.
G2: 明显的行为未被实现. 函数或者类应该实现其他程序员有理由期待的行为.
G3: 不正确的边界行为. 单元测试需要追索每个边界条件.
G4: 忽略安全. 不要忽略编译告警.
G5: 重复. 牢记DRY原则(Don't Repeat Yourself). 发现重复代码就表示遗留了抽象.,
G6: 在错误的抽象层级上的代码. 良好的软件设计要求分离位于不同层级的概念,将它们放到不同的容器.
G7: 基类依赖于派生类. 基类不应该依赖派生类. 比如部署的时候基类和派生类分属不同的jar,基类的jar文件对派生类的jar文件的内容一无所知,才能分散和独立的部署组件.
G8: 信息过多. 设计良好的模块有非常小的接口. 要限制类或模块中暴露的接口数量.类中的方法越少越好.函数知道的变量越少越好.
G9: 死代码. 未调用的代码尽早删除.
G10: 垂直分割. 变量和函数应该在靠近被使用的地方定义.
G11:前后不一致. 命名所代表的行为和意义要统一.
G12: 混淆视听. 删除未实现,未使用,无意义代码,保持代码整洁.
G13: 人为耦合
G14: 特性依赖.类的方法只应该对其所属类的变量和函数感兴趣,不该垂青其他类中的变量和函数.
G15: 选择算子参数.
G16: 隐晦的意图. 代码尽可能具有表达力.
G17: 位置错误的权责. 最小惊异原则.
G18: 不恰当的静态方法. ??
G19:使用解释性变量. ??
G20: 函数名称应该表达其行为.
G21:理解算法.
G22:把逻辑依赖改为物理依赖.
G23:用多台替代IF/ELSE或Switch/Case
G24:遵循标准约定. 每个团队都应遵循基于通用行业规范的一套编码标准.
G25:禁用魔法数. 用命名常量代替.
G26:准确 代码中的函数和不准确都是源于懒惰,都要清除
G27:结构甚于约定. 用到良好命名的枚举的switch/case要弱于拥有抽象方法的基类.
G28:封装条件.
G29:避免否定性条件.
G30:函数只该做一件事.
G31:时序耦合. 不要隐藏时序耦合.
G32:别随意.
G33:封装边界条件. 边界条件难以追踪.
G34;函数应该只在一个抽象层级上.
G35:在较高层级放置可配置数据
G36:避免传递浏览,


JAVA


J1:使用通配符避免过长的导入清单.
J2:不要继承常量.
J3: 枚举 vs 常量 .用枚举消除魔法数.


测试


T1: 测试不足
T2: 使用覆盖率工具
T3: 别略过小测试.
T4: 被忽略的测试就是对不确定事物的疑问.
T5: 测试边界条件
T6:全面测试相近的缺陷. 缺陷趋向扎堆.在讴歌函数发现一个却显示,最好全面测试那个函数.
T7: 测试失败的模式有启发性
T8: 测试覆盖率的模式有启发性
T9; 测试应该快速


如何技术选型


没有准确估计实际业务量或者说就没有估计过，导致技术选型直接参考京东、淘宝一线大公司，实现复杂，技术铺的也很大。（选型的目标是能够快速实现产品的迭代，技术够用就好）
因为缺少经验，前期业务没有明确的规划，技术选型也没有考虑高内聚、低耦合，导致系统之间依赖太强，导致现在想拆分很难。
选择了一些较新的技术框架，过于依赖几位关键的技术牛人，结果这些人一旦离职，就陷入迷茫。（框架选择要谨慎，如果选择高逼格的技术框架，需要留住核心人员，或者有备份人选）


eclipse设置




字体


普通列表项目eclipse字体推荐，专为程序员设计的字体，Source Code Pro




插件


eclipse改代码区颜色,​代码大小字体及窗口主题  eclipse改代码区颜色,​代码大小字体及窗口主题


安装地址：  http://​eclipse-color-theme.github.com/​update/ ​