代码规范
1.1.1 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束
1.1.2 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式
1.1.3 / 1.1.4 类名使用UpperCamelCase风格，必须遵从驼峰形式（某些情况诸如领域模型相关的命名除外）；方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式
1.1.5 常量命名全部大写，单词间用下划线隔开
1.1.9 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词
1.1.5
力求语义表达完整清楚，不要嫌名字长
1.1.10 杜绝完全不规范的缩写，避免望文不知义
类的命名
1.1.6
抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾
1.1.13 对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别
1.1.13 如果是形容能力的接口名称，取对应的形容词做接口名
1.1.14 枚举类名建议带上Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开
1.1.11 如果使用到了设计模式，建议在类名中体现出具体模式
1.1.9 包名统一使用单数形式；类名如果有复数含义，类名可以使用复数形式
常量规约
1.2.1
不允许出现任何魔法值（即未经定义的常量）直接出现在代码中
1.2.3 不要使用一个常量类维护所有常量，应该按常量功能进行归类，分开维护
1.2.4 常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量
1.2.5 如果变量值仅在一个范围内变化用Enum类。如果还带有名称之外的延伸属性，必须使用Enum类
1.1.12 尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量
语法糖
1.2.2
long或者Long初始赋值时，必须使用大写的L，不能是小写的l，小写容易跟数字1混淆，造成误解
1.1.12 接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁性，并加上有效的Javadoc注释
1.4.2 所有的覆写方法，必须加@Override注解
1.4.3 可变参数必须放置在参数列表的最后。（提倡同学们尽量不用可变参数编程）
1.4.4 对外暴露的接口签名，原则上不允许修改方法签名，避免对接口调用方产生影响。接口过时必须加@Deprecated注解，并清晰地说明采用的新接口或者新服务是什么
1.4.5 不能使用过时的类或方法
1.4.10 序列化类新增属性时，请不要修改serialVersionUID字段，避免反序列失败
1.4.17 循环体内，字符串的联接方式，使用StringBuilder的append
1.4.18 final可提高程序响应效率
1.4.19 慎用Object的clone方法来拷贝对象
方法命名
1.1.15
Service/DAO层方法命名规约
- 获取单个对象的方法用get做前缀
- 获取多个对象的方法用list做前缀
- 获取统计值的方法用count做前缀
- 插入的方法用save（推荐）或insert做前缀
- 删除的方法用remove（推荐）或delete做前缀
- 修改的方法用update做前缀
方法和属性
1.4.9
定义DO/DTO/VO等POJO类时，不要设定任何属性默认值
1.4.11 构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中
1.4.14 当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起，便于阅读
1.4.15 类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter方法
1.4.16 setter方法中，参数名称与类成员变量名称一致，this.成员名=参数名。在getter/setter方法中，尽量不要增加业务逻辑
1.4.20 类成员与方法访问控制从严
格式规约
1.3.5
缩进采用4个空格，禁止使用tab字符
1.3 6. 单行字符数限不超过 120 个
1.3.8 IDE的text file encoding设置为UTF-8; IDE中文件的换行符使用Unix格式，不要使用windows格式
1.3.10 方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行
注释规约
1.8.5
所有的枚举类型字段必须要有注释，说明每个数据项的用途
1.8.6 与其"半吊子"英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可
1.8.8 注释掉的代码尽量要配合说明，而不是简单的注释掉
1.8.10 好的命名、代码结构是自解释的，注释力求精简准确、表达到位
代码风格
1.7.1
在一个switch块内，每个case要么通过break/return等来终止，要么注释说明程序将继续执行到哪一个case为止；
在一个switch块内，都必须包含一个default语句并且放在最后，即使它什么代码也没有
1.7 2 在if/else/for/while/do语句中必须使用大括号，即使只有一行代码，避免使用下面的形式：if (condition) statements;
1.7.3推荐尽量少用else， if-else的方式可以改写成：
if(condition){
...
return obj;
}
// 接着写else的业务逻辑代码;
1.7.3 如果非得使用if()...else
if()...else...方式表达逻辑，【强制】请勿超过3层，超过请使用状态设计模式
1.7.4
除常用方法（如getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性
boolean existed = (file.open(fileName, "w") != null) && (...)
|| (...);
if (existed) {
...
}
来源：https://www.cnblogs.com/renyuanwei/p/9169452.html
读后感：数学模型的一类问题的解题步骤，如果研究的问题是特殊的，比如，我今天所做的事情的顺序，因为每天不一样，就没有必要建立模型。如果研究问题具有一般性，比如我要研究办银行卡，办羊城通卡，或者办其他卡的顺序，由于它们的先后次序基本相同，因此可以为办卡这一类事情建立模型。至于算法，广义的算法就是事情的次序。模型是一类问题的解题步骤，亦即一类问题的算法。由此可知，数学模型与算法是分不开的，而数学模型在生活中有很广的运用。数学之美中不要把所有的鸡蛋放在 一个篮子里-谈谈最大熵模型 就是很典型的例子。那么，何为最大熵模型？最大熵原理指出，当我们需要对一个随机事件的概率分布进行预测时，我们的预测应当满足全部已知的条件，而对未知的情况不要做任何主观假设。（不做主观假设这点很重要。）在这种情况下，概率分布最均匀，预测的风险最小。因为这时概率分布的信息熵最大，所以人们称这种模型叫“最大熵模型”.。拉纳帕提成功地将上下文信息、词性（名词、动词和形容词等）、句子成分（主谓宾）通过最大熵模型结合起来，做出了当时世界上最好的词性标识系统和句分析器。拉纳帕提的论文发表后让人们耳目一新。拉纳帕提的词性标注系统，至今仍然是使用单一方法最好的系统。在 Google 的很多产品中，比如机翻译，都直接或间接地用到了最大熵模型,达拉皮垂兄弟，用于最大熵模型和其他一些先进的数学工具股票预测，获得了巨大的成功。从该基金 1988 年创立至今，的净回报率高达平均每年 34%。也就是说，如果 1988 年你在该基金投入一块钱，今天你能得到 200 块钱。这个业绩，远远过股神巴菲特的旗舰公司伯克夏哈撒韦（Berkshire Hathaway)。同期，伯克夏哈撒韦的总回报是 16 倍。从这些真实案例可见最大熵模型在生活中的巨大应用。那么熵模型跟算法又有什么关系呢？最原始的最大熵模型的训练方法是一种称为通用迭代算法 GIS(generalized iterative scaling) 的迭代算法。八十年代，达拉皮垂(Della Pietra)在 IBM 对 GIS 算法进行了两方面的改进，提出了改进迭代算法 IIS（improved iterative scaling）。这使得最大熵模型的训练时间缩短了一到两个数量级。现在我们的生活，可以说是离不开手机，而手机中的应用程序都离不开它们的算法，生活离不开程序，而程序的编写离不开算法。至于期末写的程序我想写一个红绿灯自动切换系统，至于怎么实现我还不知道emmm，但构想应该是根据车流量来对红灯绿灯亮的时长进行判定，因为现在的红绿灯属实不太人性化，有些车流量大的路口绿灯只亮10秒导致长时间堵车。希望以后自己有能力写这样一个程序吧。
