代码规范----写出无暇代码

非本人所写，不明出处

一。让名称代表意图，使之名符其实；

  1. 单词直接要用驼峰命名，提高辨识度；
  2. 名字不要用拼音；
  3. 不要用拼音缩写或者单词缩写；
  4. 注意大小写的区分：小写的l和大写的O；
  5. 有意义的区别是尽量别用数字序列进行区分，比如a1，a2，a3.。。
  6. 无意义的子词是多余的，名称的字词直接拼接，不需要添加一些语法修饰；
  7. 参数名带用 source（资源），destination（目标）这些功能明确的词语，指定的对象明确；
  8. 能念出来帮助记忆的，语义化，读出来就知道是干什么的；
  9. 名字可以用多个单词拼接，这样描述更准确，搜索时更准确，不易造成bug；
  10. 变量前加型别，比如：let strNameCode="thomas"；字符串前面加str，let objName={age：18}，在对象前面加obj，明确是一个对象；命名前面不要加额外的自首：m_dsc=name;
  11. 类别的命名：使用准确的名词，如：customer，避免使用含糊不清的单词；如data。info。manager；
  12. 用动词修饰方法名，让别人读出来的时候知道它的功能是什么；如：postPayment；
  13. javaBean：对象修饰；取出：get；修改：set；判断：is；
  14. 简述，不要将一个功能用一个完成的短句语法表达出来，能清楚的提现功能即可；较少的名称若可以表达清楚，胜过于长名称；
  15. 在同一个应用中，不要在所有的类别钱加共同的字首，如此反而造成各个IDE中自动补齐功能无法第一时间补齐；

二.函式；

  1. 函式首要准则是简短，
  2. 使用具有描述能力的名称；
  3. 功能要无副作用，保证只做一件事；

三,注解

  1. 注解无法弥补糟糕的代码，整洁具有表达力又极少使用使用注解的代码，远优于杂乱又满是注解的代码；
  2. 真正有益的注解，是你想办法不写它的注解，让它的函数名表达出想要实现的功能；
  3. 有些需要撰写标准规范，或者著作权声明、作者资讯等，就必须且合理的注解；
  4. 对于警告其他的工程师会出现某种特殊后果的注解，也是有用的；
  5. TODO（代办事项）注解； TODO是工程师认为应该要完成的事情，但基于某些原因无法在此时做到 5.1. 提醒移除过时的功能； 5.2. 请某人注意这个问题； 5.3. 请某人寻找更好的命名； 5.4. 依赖于某个未来计划而提醒所需要的修改；
  6. 糟糕的注解： 6.1. 喃喃自语：注解表达清楚即可，别冗长和修饰 6.2. 多余的注解：不写多余的东西，或和主旨无关的东西； 6.3. 规定型注解； 6.4. 干扰型注解；写函式时别写注解，代码在压缩时可能会产生干扰；
  7. 不用的代码应该删除，而不是注解掉；

四.编排；

  1. 良好的编排有助于阅读，也显得专业；
  2. 程式码的风格与可读性，会影响程式的可维护性及可扩充性；
  3. 在垂直编排上，要尽可能的考经，相近的概念不应该分散在不同的档案里；垂直的距离用来衡量他们对彼此的了解有多重要；
  4. 水平的编排，空白间隔和密度；运算左右都加入空白，使其更为突出；函式名称和小左括号之间不空白；空白的另一种用途是强调运算子的优先权；
  5. 同一运算子，应该水平对齐，垂直对齐；
  6. 一个原始档是个阶梯结构，让视野的层次结构更为易见；

五。错误处理；

  1. 错误处理很重要，但不应该模糊原本的程式码逻辑；
  2. 较好的做法是，在你遇到一个错误的时候，抛出一个例外时间，如此，呼叫程式码就会变得干净许多；
  3. 如果你写的程式可能会抛出例外时间，请养成try-catch-finally成为习惯；
  4. 不要回传null，因为只要哦有益处忘记检查null，就会导致程式进入混乱无法控制的状态
一。让名称代表意图，使之名符其实；
二.函式；
三,注解
四.编排；
五。错误处理；