做业要求-代码规范

以后涉及编码的做业要求写明我的或团队所采用的代码规范，同窗至少制定并在做业中给出基本的缩进、命名和注释的规范，而且组内要遵循各自制定和使用的规范。

注意，制定的规范不要过分复杂或生硬套用大企业的标准，以避免过分影响开发效率；也不该太过简略，这样将难以达到规范编码的须要。

能够采用现有的规范或自行编写，但愿切实可行，容易观察和客观检验。代码不符合规范的，将扣除代码规范的分数。

例如：

• 每一个函数不超过5行，对于初学者是不切实际的;
• 大括号匹配纵列对齐，是切实可行的;
• 变量名易读，是不易检验的；
• 变量名必须是名词短语，遵循匈牙利命名法，是易于检验的。

---

这里以阿里发布的Java开发手册v1.4为准，摘取部分做为基本的代码规范示例。此处仅做示例，请同窗们根据自身状况制定合适的编码规范。

1、命名风格

1. 【强制】代码中的命名均不能如下划线或美圆符号开始，也不能如下划线或美圆符号结束。
   • 反例：_name / __name / $name / name_ / name$ / name__
2. 【强制】代码中的命名严禁使用拼音与英文混合的方式，更不容许直接使用中文的方式。
   • 说明：正确的英文拼写和语法可让阅读者易于理解，避免歧义。注意，即便纯拼音命名方式也要避免采用。国际通用的名称，可视同英文。
   • 反例：DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3
     
3. 【强制】类名使用 UpperCamelCase 风格，但如下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
   • 正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
   • 反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
4. 【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须听从驼峰形式。
   • 正例： localValue / getHttpMessage() / inputUserId
5. 【强制】常量命名所有大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
   • 正例：MAX_STOCK_COUNT
   • 反例：MAX_COUNT
6. 【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类 命名以它要测试的类的名称开始，以 Test 结尾。
7. 【强制】包名统一使用小写，点分隔符之间有且仅有一个天然语义的英语单词。包名统一使用单数形式，可是类名若是有复数含义，类名可使用复数形式。
   • 正例：应用工具类包名为 com.alibaba.ai.core.util、类名为 MessageUtils（此规则参考 spring 的框架结构）
8. 【强制】杜绝彻底不规范的缩写，避免望文不知义。
   • 反例：AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成 condi，此类随 意缩写严重下降了代码的可阅读性。
9. 【推荐】为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽可能完整的单词组合来表达其意。
   • 正例：在 JDK 中，表达原子更新的类名为：AtomicReferenceFieldUpdater。
   • 反例：变量 int a 的随意命名方式。

2、代码格式

1. 【强制】大括号的使用约定。若是是大括号内为空，则简洁地写成{}便可，不须要换行；若是是非空代码块则：
   • 左大括号前不换行。
   • 左大括号后换行。
   • 右大括号前换行。
   • 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。
2. 【强制】if/for/while/switch/do 等保留字与括号之间都必须加空格。
3. 【强制】采用 4 个空格缩进，禁止使用 tab 字符。

3、注释规约

1. 【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用 // xxx 方式。
   • 说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 能够正确输出相应注释；在 IDE 中，工程调用方法时，不进入方法便可悬浮提示方法、参数、返回值的意义，提升阅读效率。
2. 【强制】全部的抽象方法（包括接口中的方法）必需要用 Javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法作什么事情，实现什么功能。
   • 说明：对子类的实现要求，或者调用注意事项，请一并说明。
3. 【强制】全部的类都必须添加建立者和建立日期。
   
4. 【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐。
5. 【强制】全部的枚举类型字段必需要有注释，说明每一个数据项的用途。
6. 【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文便可。
   • 反例：“TCP链接超时”解释成“传输控制协议链接超时”，理解反而费脑筋。
7. 【推荐】代码修改的同时，注释也要进行相应的修改，尤为是参数、返回值、异常、核心逻辑等的修改。
   • 说明：代码与注释更新不一样步，就像路网与导航软件更新不一样步同样，若是导航软件严重滞后，就失去了导航的意义。
8. 【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。若是无用，则删除。
   • 说明：代码被注释掉有两种可能性：
     • 后续会恢复此段代码逻辑。
     • 永久不用。
   • 前者若是没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。

---

参考资料：

Coding conventions
[https://en.wikipedia.org/wiki/Coding_conventions]

Programming style
[https://en.wikipedia.org/wiki/Programming_style]

Google Style Guide
[https://github.com/google/styleguide]

阿里巴巴Java开发手册
[https://files-cdn.cnblogs.com/files/han-1034683568/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4Java%E5%BC%80%E5%8F%91%E6%89%8B%E5%86%8C%E7%BB%88%E6%9E%81%E7%89%88v1.3.0.pdf]

.NET框架设计准则
[https://docs.microsoft.com/zh-cn/dotnet/standard/design-guidelines/]

团队项目开发"编码规范"系列文章
[http://www.cnblogs.com/huyong/archive/2011/03/18/1988423.html]

C#编码规范
[http://www.cnblogs.com/wulinfeng/archive/2012/08/31/2664720.html]

咱们的终极编码规范
[http://www.cnblogs.com/leotsai/p/our-ultimate-coding-standards.html]

本身总结的C#编码规范
[http://www.cnblogs.com/luzhihua55/p/CodeConvention7.html]