• 编码规约

1.1规约缘起

       软件系统是一个协作的产物，而为了能更好更高效的完成多人协作，则需要所有的参与者都在一个共同的认知基础上，这个共同的认知应该是大家的认可的公认的优秀的理论和规则。所以为了更好的完成软件协作需要大家订立一个共同遵守的规约来指导具体的开发工作。在协作的过程中通常会出现类似帕金森琐碎定律的情况。

帕金森琐碎定律介绍

       帕金森琐碎定理（英语：Parkinson's Law of Triviality），又译为帕金森氏凡俗法则，或称芝麻蒜皮定律、芝麻绿豆定律，由英国历史学者与政治学者西里尔·诺斯古德·帕金森（Cyril Northcote Parkinson）于1957年所提出，用来说明大型组织会花费大量时间在讨论无关紧要的琐事，但是真正重大的决议反而可以轻松过关这种现象。

       这是由于人对大议题较难有全面性的理解，故怕贸然提出异议，可能会失言；相反地，对于一些简单琐碎的小事，有相当的认识，因此意见特别多，造成组织在各事项上讨论所花费之时间，通常与事项本身的重要程度呈现反比。

所以订立一个开发规约是非常有必要和意义的。

1.2规约的好处

       规约订立之后在该规约之上的所有参与者都在同一个基础上进行沟通协作，这样减少成员之间的分歧，沟通理解更加容易，大大减少彼此的沟通时间成本具体如下。

       1.减少代码的维护成本

       2.改善可读性

       3.减少沟通成本提高了效率

       4.保留住人才，好的规约建立好的工作氛围这样更容易留着人才.

国内业界比较公认的优秀规约就有阿里巴巴的《java开发手册》

其发布时间如下

1.3规约的内容

• 代码风格

       好的风格是简单清爽。

• 命名风格与代码格式

• 常量的定义与设计规约：

       必须使用常量魔法值定义为常量，否则复制来回可能导致重大问题。      

一定要表意清晰确定，不要为了节省字段。

       JDK的经典常量

• 注释规约

       错误的注释

1.注释的作用

2.注释类型

注释规约

实体类

• 前后端的设计规约

2.1前后端设计规约

• 前后端纠结点

• 前后端交互的API

• 前后端规约

1.把系统错误和用户提示映射起来，不要把系统错误直接提示给用户。

       2.java与JS对数字类型变量处理方式不同，如果数字太大或者有精度要求，最好使用String类型。

看看如下代码运行结果

结果是2个都是true；

0.25F与0.5F有什么特征？转换为2进制时是整数，0.25是2的-1,0.5是2的1，不会出现小数位

而0.9F与0.8都不是2进制的整数，所以相减之后得到的也是平均数。

结果是2个都是false；

代码是一样的情况下为什么出现了都是true和false？

浮点数的计算误差

如果a-b=？

结果是0.100000024

为什么要有科学计数法？

为了表达极大数和极小数的，但是计算机能表示的位数是有限的，

Float：比特数为32位i，有效位数为7位数（十进制），数字范围：

所以对于

对于浮点数

将float转换为int，float 的to方法

0.9=9*10

演示将0.375转换为二进制

而JS

二进制的规格化只有1个，十进制的规格化只有9个，所以有一个1是忽略的。

双精度的浮点数的指数位数为17位，有效位数11位数,52位数的有效。

double总的有效位数是53位数，

所以前端传给后端如果值大于2的53次方则数据会出现丢失。

因为JS是个弱类型的语言，数字必须使用科学计数法表示Double浮点数。

因此如果要将long值传给前端应该定义为String类型，这样不会截断。

• 前后端规约

1．数据类型

如果从后端传递到前端的值是2的56次方能精确表示吗？

答案是：能，因为只要是2的整数次方不会造成精度损失，但是如果使用js时会丢失位数，因为

如果有个方法f（String）和f（Integer）

如果调用使用f（null）应该调用哪个方法？

答案是：编译不同

如果有继承树，从继承树的底部开始找方法（父类为上，子类为子）

如果有方法f（String）和f（Object）时，如果f（null）时调用哪个方法？

答案是：f（String）

2.协议

       Http的头部传值长度不应该超过2048,因为2048是个安全值。，超过的可能不安全。