阿里编码规范学习

针对附录中的阿里编码规范,直接指定标题位置,或列出相应规范内容,与其说是编码规范,不如说是新手防坑指南,菜鸟们很值得一看。

一编码规范

(一)命名规约

6.【强制】抽象类命名使用 Abstract 或 Base 开头;异常类命名使用 Exception 结尾;测试类 命名以它要测试的类的名称开始,以 Test 结尾。

7.【强制】中括号是数组类型的一部分,数组定义如下:String[] args;

    个人理解:禁止使用String args[]。同时数组创建又分为动态创建和静态创建,

    静态:int intArray [] = {30,31,32};

    动态:int[] intArray = new int[3];

  动态数组能够在实际应用中改变长度,arrayList就是一个复杂的动态数组。静态不能改变长度。

8.【强制】POJO 类中布尔类型的变量,都不要加 is.

    个人理解:容易造成某些框架的或关键字的识别混乱。

12. 【推荐】接口类中的方法和属性不要加任何修饰符号(public 也不要加)

    个人理解:因为接口中的方法等一定要被实现,所以除了public都没什么意义。既然只能加public那就直接省略了,将其默认为public

13.【强制】很多人对实现类命名时使用的时imp。这里建议使用impl,就是为了统一标准。统一的命名规范能够更好的利用通配符,例如调包时xxx.com.test.*.impl。

13.【参考】方法命名规则。统一方面命名规则后能够直接通过方面名就知道方法的大概通途。如:查询单个对象用get。

(二)常量定义

1. 【强制】不允许出现任何魔法值(即未经定义的常量)直接出现在代码中。反例: String key="Id#taobao_"+tradeId;

    个人理解:解决硬编码问题。方便后期维护及全家利用。

3. 【推荐】不要使用一个常量类维护所有常量,应该按常量功能进行归类,分开维护。

5. 【推荐】如果变量值仅在一个范围内变化用 Enum 类。

正例:public Enum{ MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);}

(三)格式规约

5. 【强制】缩进采用 4 个空格,禁止使用 tab 字符。

6. 【强制】单行字符数限制不超过 120 个,

7. 【强制】方法参数在定义和传入时,多个参数逗号后边必须加空格。

10. 【推荐】不同业务逻辑和语义之间要插入一行(仅一行)空行。

(四)OOP规约

3. 【强制】相同参数类型,相同业务含义,才可以使用 Java 的可变参数,

8. 【强制】关于基本数据类型与包装数据类型的使用标准如下: 1) 所有的 POJO 类属性必须使用包装数据类型。 2) RPC 方法的返回值和参数必须使用包装数据类型。 3) 所有的局部变量【推荐】使用基本数据类型。

  个人理解(1)和(2)中使用基本类型时,初始化或返回值为null时会默认为0,如果0有特殊含义将会造成不必要的异常。对于(3)中的理解。局部变量随着方法的存在而调用,随着方法的销毁而销    毁。如果是封装类型,当我们多次调用这个方法时,就会创建很多次封装类型的变量,如果用基本类型则会避免。

9. 【强制】定义 DO/DTO/VO 等 POJO 类时,不要设定任何属性默认值。

  个人理解:更新操作的时候可能产生错误数据,例如时间字段。

17. 【推荐】循环体内,字符串的联接方式,使用 StringBuilder 的 append 方法进行扩展。

  个人理解:减少new String的次数,节省内存

(五)集合处理规则

1. 【强制】关于 hashCode 和 equals 的处理,遵循如下规则:

  1) 只要重写 equals,就必须重写 hashCode。 2) 因为 Set 存储的是不重复的对象,依据 hashCode 和 equals 进行判断,所以 Set 存储的 对象必须重写这两个方法。 3) 如果自定义对象做为      Map 的键,那么必须重写 hashCode 和 equals。

  个人理解:避免equals相等时,hashCode不相等。equals()相等的两个对象,hashcode()一定相等;equals()不相等的两个对象,却并不能证明他们的hashcode()不相等。

2. 【强制】ArrayList的subList结果不可强转成ArrayList,否则会抛出ClassCastException 异常:

  个人理解:subList后只是在原ArrayList基础上拿我想要的部分。对原集合和subList视图集合操作时会相互影响。

(未完待续)

    

时间: 2024-08-24 16:42:35

阿里编码规范学习的相关文章

编码规范学习总结

164173422 陶冶 GitHub 地址 https://github.com/fishmanIs 自己的错误 错误1:毫无意义的命名 案例: 错误2:命名抽象不合理 案例: 错误3:命名格式不规范 案例:第一张未使用WinForm Control 命名规范,第二张私有变量命名格式错误 错误4:卖弄风骚(大概算是 案例: 错误5:注释多余.没解释清楚 案例: 错误6:注释代码 案例: 施金鑫的错误 错误1:毫无意义的命名 案例: 错误2:命名不合理,难以理解 案例:第一张图中的count,第

Javascript编码规范学习

http://javascript.crockford.com/code.html文章学习笔记. 1.使用js文件管理代码 所有代码尽量放在js文件中,然后再html文件中使用script引入,引入时注意放在body标签后面,并且不使用type或者language. 2.书写缩进 使用4个空白格缩进,注意不要使用tab键进行缩进. 3.断句 注意行长,每行不超过80个字符,超过时要进行适当断句,断句应该再操作符后面进行,最理想的是在逗号(,)后面进行断句,断句后下一行使用8格缩进. 4.注解 一

Python编码规范学习

Python 风格规范(Google) 本项目并非 Google 官方项目, 而是由国内程序员凭热情创建和维护. 如果你关注的是 Google 官方英文版, 请移步 Google Style Guide 以下代码中 Yes 表示推荐,No 表示不推荐. 分号 不要在行尾加分号, 也不要用分号将两条命令放在同一行. 行长度 每行不超过80个字符 以下情况除外: 长的导入模块语句 注释里的URL 不要使用反斜杠连接行. Python会将 圆括号, 中括号和花括号中的行隐式的连接起来 , 你可以利用这

阿里Java编码规范

详细,全面 很不错 阿里 Java编码规范

《从零开始学Swift》学习笔记(Day 57)——Swift编码规范之注释规范:

<从零开始学Swift>学习笔记(Day 57)--Swift编码规范之注释规范:文件注释.文档注释.代码注释.使用地标注释 原创文章,欢迎转载.转载请注明:关东升的博客 前面说到Swift注释的语法有两种:单行注释(//)和多行注释(/*...*/).这里来介绍一下他们的使用规范. 文件注释 文件注释就在每一个文件开头添加注释,文件注释通常包括如下信息:版权信息.文件名.所在模块.作者信息.历史版本信息.文件内容和作用等. 下面看一个文件注释的示例: /* Copyright (C) 201

学习一份百度的JavaScript编码规范

JavaScript编码规范 1 前言 2 代码风格 2.1 文件 2.2 结构 2.2.1 缩进 2.2.2 空格 2.2.3 换行 2.2.4 语句 2.3 命名 2.4 注释 2.4.1 单行注释 2.4.2 多行注释 2.4.3 文档化注释 2.4.4 类型定义 2.4.5 文件注释 2.4.6 命名空间注释 2.4.7 类注释 2.4.8 函数/方法注释 2.4.9 事件注释 2.4.10 常量注释 2.4.11 复杂类型注释 2.4.12 AMD 模块注释 2.4.13 细节注释 3

PHP编码规范建议学习

###php编码规范 -------* sql过长 ```$sql = <<<SQLSELECT delivery_idFROM d_testWHERE delivery_idIN (123,234)GROUP BY delivery_idHAVING SUM(send_number) <= 0;SQL;```* if等控制结构条件过长 ```if ($a > 0 && $b > 0 && $c > 0 && $d

编码规范与数学之美感想

命名规约 代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束 代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式 类名使用UpperCamelCase风格,必须遵从驼峰形式(某些情况诸如领域模型相关的命名除外):方法名.参数名.成员变量.局部变量都统一使用lowerCamelCase风格,必须遵从驼峰形式 常量命名全部大写,单词间用下划线隔开 包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词 抽象类命名使用Abstract或Base开头:异常类命

PHP 高级程序设计(1) - 编码规范及文档编写

PHP 高级程序设计学习笔记20140612 软件开发中的一个重要环节就是文档编写.他可以帮助未来的程序维护人员和使用者理解你在开发时的思路.也便于日后重新查看代码时不至于无从下手.文档还有一个重要的作用,在不用了解要访问对象的细节情况下也能很好的在对象之间进行交互.文档的编写有一些成熟的行业标准格式,遵守这些行业标准将有助于创建易于阅读的代表,并使自动生成手册成为可能. 编码规范 编码规范可能很多开发人员都有各自的观点也意见,且大家不尽相同.其实只要团队成员之间达成一致,遵循同一个标准就好.