代码规范

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 抽象类命名使用AbstractBase开头;异常类命名使用Exception结尾;测试类命名以它要测试的类的名称开始,以Test结尾

1.1.13
对于ServiceDAO类,基于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
循环体内,字符串的联接方式,使用StringBuilderappend

1.4.18 final
可提高程序响应效率

1.4.19
慎用Objectclone方法来拷贝对象

方法命名

1.1.15  Service/DAO层方法命名规约
-
获取单个对象的方法用get做前缀
-
获取多个对象的方法用list做前缀
-
获取统计值的方法用count做前缀
-
插入的方法用save(推荐)或insert做前缀
-
删除的方法用remove(推荐)或delete做前缀
-
修改的方法用update做前缀

方法和属性

1.4.9 定义DO/DTO/VOPOJO类时,不要设定任何属性默认值

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 算法进行了两方面的改进,提出了改进迭代算法 IISimproved iterative scaling)。这使得最大熵模型的训练时间缩短了一到两个数量级。现在我们的生活,可以说是离不开手机,而手机中的应用程序都离不开它们的算法,生活离不开程序,而程序的编写离不开算法。至于期末写的程序我想写一个红绿灯自动切换系统,至于怎么实现我还不知道emmm,但构想应该是根据车流量来对红灯绿灯亮的时长进行判定,因为现在的红绿灯属实不太人性化,有些车流量大的路口绿灯只亮10秒导致长时间堵车。希望以后自己有能力写这样一个程序吧。