网上一搜能搜出一大把出来，这里只是根据自己的工作经验总结下日常的书写规范。
1.代码不仅是写给自己看，也是写给别人看的。（可能过了很久，你也成了陌生人，看着也是一脸懵逼）
2.注释很重要，关键节点/特殊需求/不确定不明白的地方
3.精确描述变量/方法名含义,做到一语中的。a.提高词语概况能力，不断提炼/概括的过程 也是对业务的熟悉度的掌握 b.清晰表达逻辑
4. 一个方法尽量不超过50行。这只是一个概念在脑海中就好，并非所有方法都能那么简短。a.一段几百行的代码肯定能够通过封装和缩减成几个方法，拆分成可复用的几部分，方便日后修改和删除。 b.短的方法，能够全部显示在一屏之内，方便查看和阅读，上翻下翻也是很痛苦的。
5.一个方法只做一件事，同一件事只用一个方法。与第四点相通，可复用，有效减少冗余代码，也使日后容易根据新需求进行删除/修改。
6.三目运算符的使用。经常有很多if else的判断只是简单的赋值，要用掉5行的空间，三目运算符(a = flag ? b : c)一行搞定,完美
7.对于局部的代码来说（一个类、方法内），逻辑肯定是简单的。如果你感觉你写的很复杂?那肯定是有地方没搞清楚，再缕缕，再设计看看，在时间允许的情况下，看看有没有另外的方案，不行就多写注释。只有相对简单逻辑和代码才是健壮的，可读性强，查错/定位更加容易。不清晰的代码往往隐藏着bug的风险。
8.如何改bug？千万不要去试图重构，修改重大逻辑，可能会引发更大的bug。设计模式有个原则叫开闭原则，即对扩展是开放的，对修改是关闭的。因为以前的逻辑是经过验证的，之后改出了问题你就要背锅。本着不背锅的 原则，应当写一些新的业务方法，在合适的地方加入，尽量保持小的变动。最理想的情况是，增加了业务方法A(),B(),C()...，最后只有方法A()添加到原来的逻辑之内。
9.变量名、类方法的命名。比如类名MessageManager， 内部定义的变量应当不再出现message的字眼，感觉重复了。比如messageID ->> id;messageContent - >> content.； public void addMessage() ->> public void add();在外部调用的时候MessageManager.getId() MessageManager.getContent MessageManager.add().不过这个看个人习惯，个人感觉不写简洁一点。
暂时想到这么多。未完待续
