作为一个默默无闻的大二码农学生，虽然在学校小有名气，但是当看到java规约的时候，就像看到了新世界一样！
看完了规约，现在能回想起来的几点还是先复习下~
其一，以前习惯的括号换行风格，现在也在渐渐在适应不换行风格了（同时听老师说扣工资扣绩效到到怕），当时觉得括号换行不换行不应该加入到规约中，毕竟现在的IDE有format功能，也想到代码比对就会成问题了，所以还是果断改了！！其它的很多代码习惯还好是以前就养成了，所以也没有那么多需要改的问题。
其二，关于几个表的null值问题，我倒是还真没有遇到过这个坑，好在看完规约知道了，还有很多的安全规范也会不断的去看。
其三，HashMap不要用KeySet方式而用EntrySet方式
其四，记住了<? extends T>泛型不能使用add方法（之前正好遇到这个坑，好像现在也有点忘了。。。）
其五，万恶的教训——一定要“为了自己”写注释！！！
刚刷新了下规约页面，看到应该更新到V1.02了，但是我没有兴奋啊！！！因为。。。看图（要怎么让我改到新版本去。。。）

（我这么认真地标注记录学习规约，小编不奖励我个笔记本让我再认真一遍吗？！（手动滑稽））

话说 现在ThreadLocal不是自动清理了么。

HashMap 要不加锁， 要不使用 ConcurrentHashMap，有一次CPU居然飙到1120% 。

毕竟Stringbuffer 是线程安全的 ，影响性能也是必须的。

需要维护别人写的恶心代码而有想重构的冲动。

隔段时间，看自己写的代码 都有种恶心的感觉，哈哈哈哈哈哈哈哈~~~

主攻java web，也了解一些js和c#的的基础，不管什么语言最令人纠结的还是命名方式和名称的选择，包括变量、类名、方法、文件夹、jsp文件等等eeeeeverything，正如标题所说，到底该用驼峰还是下划线？一不小心就拼成令人尴尬的chinglish怎么办？

强迫症表示最怕的是看别人的代码，有直接用中文变量名的，还有压根没有驼峰的（就和文章没有标点符号一样能不能看懂完全靠猜），心中无数草泥马奔腾有木有！有木有！！其实我觉得不管怎样命名，只要在符合命名规范的前提下，让它看起来酷酷哒就行了对吧。

另外说个近期让人泪奔的经历，项目上遇到了编码问题，我就屁颠屁颠的用notepad++和eclipse双管齐下调整编码，最后发现有部分文件的注释乱码了不管你怎么调都调不回来了，可以说是经历过绝望了，最后只能将上千行代码的注释全部重写，忠告各位在整编码的时候务必backup一下。

最后，请各位客户端程序员在处理异常的时候一定用throws抛出，让业务层程序员去处理，千万不要偷偷的try起来！！！

大一时候，我看到一篇文章讲到作者自己曾在大学写的一个得意软件交给业内好友评价，一盏茶的时间指出了代码中的n个问题。该作者在后面就论证了代码规范问题。在那时候我刚学完C，正学C++，就在思考代码怎么更清晰明了。这篇文章，则成为我编码习惯的启蒙。之后的那段时间，我一直很刻意的保持代码尽量规范，有时候想一个变量名字都要很久…:我忽然觉得这是不是强迫症？嗯，不是！比起编码，如果去维护 int a；int b；而强迫自己去认真看这些糟糕代码，这更是强迫症……
也许——人总是对别人更有信心(他信力)。自己写一款软件，往往没什么底气，总担心未知bug，而对运行别人的代码，就显得信心较足。
感觉自己的规范不太好，一直希望能看到大公司的编码规范……

直到最近，看到阿里云的Java开发规范……

好吧，我承认，我是看到那个奖品的定制笔记本——才舍得动手码字的，因为我的笔记本已经追随我近四年了，也没舍得换…

对于程序员来说，编程规范可以养成良好的编程习惯，提高代码质量，降低沟通成本。就在2月9号，阿里出了一份Java开发手册(正式版)，分为编程规约，异常日志，MySQL规约，工程规约，安全规约五个章节，写的非常好，但由于最近很忙，只看了一般左右。

1. 注释往往关系到代码的品质， 写注释的时候也要注意写得更清晰一点。
2. 注释也不应该用大的框框包围起来， 比如用*号或其它的字符画的框框。
3. 注释不应该含有特殊的字符， 比如退格键等。
   一个公司或者开发一个项目，大家如果规定好注释的规范，每个人都按照要求来，看起来非常清楚，编写代码的时候就可以加强代码的耦合度。就像最近在写的一个项目，由于我没有详细规定注释的规范，大家写的代码读起来非常的累，只能返工让他们把自己应该需要的注释都加上。养成了写注释的好习惯，会减少许许多多不必要的麻烦。

我用中文编程，相当多的地方适合英文。主要是在过程内部规范更为突出。就说说变量规范吧，我称之为zcd法则，这是一套对变量进行分类应用，同时利用编辑器的智能感知，自动提示变量，毕竟记忆分类比记忆所有变量简单高效的多。c是参数，d是递出，z是自用，其实z部份可以根据具体情况进行再细一点的分类，一般5类足够，仅仅3类的时候居多。分类是利用过程内部类实现，这样仅仅录入“c.”就会列出里面所有变量，然后选择，设计程序高效多了。同时过程的结构也做了规范，由变量的创建到释放，参数的检验等等。
好处一：就是还充份利用代码折叠，将非业务代码尽可能的折叠，仅保留必要的说明，而业务代码展开，这样在查看代码时，精力更多的用在业务逻辑分析上。好处二：由于过程的规范，非业务代码大同小异，可复制增强，所以1、完全可复制后，稍加修改；2、做到及时通知虚拟机释放，无需另外写代码；3、利用副本技术，解决内存占用与速度之间的矛盾，或重复利用与初始化之间的矛盾。好处三：预防不必要的问题出现。
缺点就是，用文本编辑器查看，代码变得冗长。这是因为这套规则利用编辑器自身特性衍生出来的。
其他还有类名、过程名、临时变量名、变量名等的规范，就不一一道来。希望借助阿里的规范，将自己的规范更上一层楼。

一直觉的，开源项目的代码很难读懂，明明只要一个类就能完成的功能，偏偏要定义接口，虚拟类，子类1，子类2，分支子类1，分支子类2......。在遇到BUG的时候，调试器，各种跳，一会跳到这个实现类，一会跳到那个虚拟类，把头都搞炸，感觉完全理不清代码框架。
但是，这就是规范，为了更好的定义功能，更好的扩展性。我没有理清楚完全是我没有这个意识，在认真分析完spring的一个开源子项目后，我开始受益，开始觉的，这个接口好优美，还可以让我自己实现更美好的实现。自己的代码也开始往这个方向编写,耦合性得到充分改善，先思考后编写，先定义接口，再实现它。
总结：i like 规范！

规范很重要，好的规范更重要，这个文档真的可以改变很多人的代码习惯。

     之前在上课的时候，写程序的老师和我们说：
    你写的程序不仅仅你自己要看懂，我也要看懂<这里的“我”是我老师>。将来如果有人要用到你的程序，那么你还要让看你程序的人看懂。

当然，像众多初学者一样，我不以为然。那时的我，虽然会给自己的代码添加注释，但是位置时长是歪七扭八。没有统一的缩进格式。会把苹果这个单词拼成pingguo.............以及很多规范性的错误。

总是有进步的，随着时间的迁移。我逐渐的升到了大三。看过了很多代码，写过了很多程序。逐渐的知道“写垃圾代码的人是没有人要的”，所以，时刻要求自己写出整齐有序的代码。现如今，我用别人玩ＬＯＬ的时间开发了自己的个人网站，并且自学了前端开发和一些有关硬件的知识。我希望能够在程序的道路上走的更远。对了，我还在大学养了两只猫咪，所以我的ＩＤ叫做猫咪。

非常喜欢一些社区定制的一些小物件，包括文化衫，还有公仔之类的。希望能够得到一个吧。嘿嘿～　就写这么多了,希望社区能送我一个小笔记本或者小公仔吧，我可是不贪心的哦～　

公司的好多项目都是JSP+Servlet完成的，感觉好 low，前后端都没有分离，维护起来特别麻烦，源码都没了，都是通过反编译的代码维护，真是无语了

作为一个java攻城狮，面对编码规约，我有话要说。公司每次需要我review别人的代码的时候，都有一种隐隐的痛，面对一些无法直视的代码，通常我会细改之，还会多给别人提提建议，以下是我觉得比较重要的几点，需要大家共同遵守的规范。1.只要重写equals方法，就一定要重写hashCode的方法 2.在并发的删除操作中，要对Iterator对象加锁 3.集合初始化时，要对集合初始化大小 4.对资源进行锁时，要保持一致的加锁顺序，避免造成死锁 5.在事务代码中，需要回滚事务，要手动回滚事务 ，还有很多规约需要我们在开发的过程中吸取经验教训，接近业界的标准。

3.1.15条 “正例：人的年龄用unsigned tinyint（表示范围0-255，人的寿命不会超过255岁）；海龟就必须是smallint，但如果是太阳的年龄，就必须是int；如果是所有恒星的年龄都加起来，那么就必须使用bigint。”
这里存在数量级估算错误，太阳年龄在50亿年左右，已经超过int了（unsigned int上限是2^32-1约41亿），所有恒星年龄加起来一定超过bigint（银河系就有差不多1000亿颗恒星了，每个恒星按100亿年算，乘起来一定超过2^64）。

final 变量 为马 全大写 好丑啊 为马不首字母大写即可？

建议增加单元测试的内容，不同的程序写了的junit，差异太大，特别是涉及复杂业务逻辑的，需要进行严格规范。

现有的java项目，没有单元测试是非常不合适的，各类单元测试代码，若项目的可用性要求高一些，有的会比业务代码还多。
各类的测试代码，也是软件代码价值的重要组成，后续的维护等，也有非常大的成本。

单位测试的规范细分类，可考虑根据是否有关连数据库等，依据硬件资源进行细分类。

去年年底刚检视到的代码，以前一直以为是传说，没想到让我碰到真的了。
你见过下面的常量定义么：
int ONE=1;
int TWO=2;
int THREE =3;
......
int TEN=10;

Final 让偷懒，变成不可能

开发规约很赞，如何将开发规约落地于日常开发如 IDE 编码规范约束，如何集成到日常持续集成比如如何与 git 集成，如何和 ci 服务如 hudson等集成个人觉得应该是有体系落地的

技术服务方案越来越全了

建议增加单元测试的规范内容，因为代码可测是敏捷开发和可维护代码的重要保证。
要把代码写成可以测试的，还要方便测试，例如一个代码是延时30分钟才会清除缓存，然后方便测试的代码应该是 缓存时间可以作为参数控制，然后测试时候，设置为1s，然后跑测试就1s就跑了，不用浪费30分钟。

我记得看过阿里java规约，总结挺好
应用分层

1.分层如下
　　1）开放接口层：可以直接封装Service接口暴露成RPC；通过web封装成http接口；网关控制层等。
　　2）终端显示层：各个端的模板渲染并执行显示层。
　　3）Web层：主要是度访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理。
　　4）Service层：对具体的业务逻辑进行处理。
　　5）Manager层：通用业务处理层
　　　　1️⃣ 对三方库的接口，预处理返回结果及转化异常信息；
　　　　2️⃣ 对Service层通用能力的下沉，如缓存方案、中间件通用处理；
　　　　3️⃣ 与DAO层交互，对DAO的业务通用能力的封装。
　　6）DAO层：数据库访问层。
　　7）外部接口或者第三方平台：包括其他部门RPC开放接口，基础平台，其他公司的http接口。

 二方库规约

1.二方库版本号（Version）命名方式：主版本号.次版本号.修订号
　　1）主版本号：当做了不兼容的API修改或者增加了能改变产品方向的新功能。
　　2）次版本号：当做了向下兼容的功能性新增。
　　3）修订号：修复bug，没有修改方法签名的功能增强，保持API兼容性。

服务器规约
1.服务器内部重定向必须使用forward；外部重定向地址必须使用URL Broker生成。

安全规约
1.可以被用户访问的功能必须做权限控制，shiro。
2.用户敏感数据禁止直接显示，必须对展示数据脱敏。
3.用户请求传入的任何数据必须做有效性验证。

规范是很重要，但是有时候只考虑规范的话，又会影响开发效率或者说是速度。这种矛盾似乎很难解决，特别是在小项目上。项目越小，就越需要考虑成本（即开发速度）。项目越大，越需要考虑规范