代码规范与计划安排
这个作业属于哪个课程 | 至诚软工实践F班 |
---|---|
这个作业要求在哪里 | 第五次团队作业:项目冲刺 |
团队名称 | 代码敲的都队 |
这个作业的目标 | 规定代码规范,明确冲刺阶段计划与目标 |
一、代码规范
1、核心原则
因为软件是需要人来维护的,代码应该简洁易懂,逻辑清晰
- 不要过分追求技巧,降低程序的可读性。
- 简洁的代码可以让bug无处藏身。
2、命名规范
- 所有编程相关的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束。
- 所有编程相关的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。
- 首字母小写,之后每个单词首字母都大写(小驼峰法命名法)
- 常量命名应该全部大写,单词间用下划线隔开。
- 避免在子父类的成员变量之间、或者不同代码块的局部变量之间采用完全相同的命名,使可理解性降低。
- 不使用不规范的英文缩写,避免可读性低。
3、代码格式
- 程序块要采用缩进风格编写,缩进的空格数为4个,避免使用Tab进行缩进。
- 每一行的字数限制为80个字数限制。
- 循环、判断等语句中若有较长的表达式或语句,则要进行适应的划分,长表达式要在低优先级操作符处划分新行,操作符放在新行之首。
- 不允许把多个短语句写在一行中,即一行只写一条语句。
- if、for、do、while、case、switch、default等语句自占一行,且.if、for、do、while等语句的执行语句部分无论多少都要加括号{}.
4、注释规范
(1)注释原则
-
优秀的代码大部分是可以自描述的,我们完全可以用程代码本身来表达它到底在干什么,而不需要注释的辅助。
-
但并不是说一定不能写注释,有以下三种情况比较适合写注释:
- 公共接口(注释要告诉阅读代码的人,当前类能实现什么功能)。
- 涉及到比较深层专业知识的代码(注释要体现出实现原理和思想)。
- 容易产生歧义的代码(但是严格来说,容易让人产生歧义的代码是不允许存在的)。
-
除了上述这三种情况,如果别人只能依靠注释才能读懂你的代码的时候,就要反思代码出现了什么问题。
-
最后,对于注释的内容,相对于“做了什么”,更应该说明“为什么这么做”。
(2)注释规范
- 类、类属性、类方法的注释使用 /** 内容 */ 格式。
- 方法内部单行注释,在被注释语句上方另起一行,使用 // 注释。方法内部多行注释使用 /* */注释,注意与代码对齐。
- 选择熟悉的、可以正确表达代码含义的语言进行注释,不必追求英文注释。
5、可读性
- 注意运算符的优先级,并用括号明确表达式的操作顺序,避免使用默认优先级。
- 避免使用不易理解的数字,用有意义的标识来替代。
- 源程序中关系较为紧密的代码应尽可能相邻。
二、预期计划与预期目标
计划天数 | 任务计划 | 预期目标 |
---|---|---|
第1天 | 小组会议探讨任务分配,了解各自任务与学习方向 | 分工完善 |
第2天 | 学习知识,完成部分前后端代码的开端 | 初步熟悉后开始进行各个页面任务的编写 |
第3天 | 前端完成基础页面设计后端完成部分模块代码 | 设计查看共享物品相关的前端页面,实现登录注册相关的后端业务逻辑 |
第4-8天 | 前端尽量实现页面跳转,后端对物品查看功能进行编码和设计 | 新增相关合理功能 |
第8-9天 | 前端进行界面优化,后端继续对各个功能进行编码 | 逐步加深,并继续完善后端代码 |
第10天 | 前端完善页面并对相应代码进行修改和代码规范,后端继续编码 | 对已完成的页面进行测试,解决BUG |
第11天 | 前端测试、后端根据测试,修改并完善功能 | 前后端完成预期任务 |
第12天 | 收尾工作,验收最后成功、Bug修改和后期维护 | 项目完成,汇总冲刺 |