代码规范与冲刺计划

一、代码规范

1、命名

1、命名的长度选择

关于命名长度，在能够表达含义的额情况下，命名当然是越短越好。在大多数的情况下，短的命名不如长的命名更能表达含义，很多书籍是不推荐使用缩写的。

2、利用上下文简化命名

3、命名要可读、可搜索

“可读”，指的是不要用一些特别生僻、难发音的英文单词来命名。

4、如何命名接口

对于接口的命名，一般有两种比较常见的方式。一种是加前缀“I”，表示一个Interface。比如IUserService，对应的实现命名为UserService。

2、注释

1、注释到底该写什么

我们写数注释的目的是让代码更易懂，注释一般包括三个方面，做什么、为什么、怎么做。
1、注释比代码承载的信息更多
2、注释起到总结性作用、文档的作用
3、一些总结性注释能让代码结构更清晰

2、注释是不是越多越好

注释本身有一定的维护成本，所以并非越多越好。结构体和函数一定要写注释，而且要写得尽可能全面、详细，而函数内部的注释要相对少一些，一般都是靠好的命名、提炼函数、解释性变量、总结性注释来提高代码可读性。

3、代码风格

1、函数多大才合适

函数的代码太多和太少，都是不太好的
太多了：

一个方法上千行，一个函数几百行，逻辑过于繁杂，阅读代码的时候，很容易就会看了后面忘了前面

太少了：

在代码总量相同的情况下，被分割成的函数就会相应增多，调用关系就会变得更复杂，阅读某个代码逻辑的时候，需要频繁地在n多方法或者n多函数之间跳来跳去，阅读体验也不好。

多少最合适的呢？

不过很难给出具体的值，有的地方会讲，那就是不要超过一个显示屏的垂直高度。比如，在我的电脑上，如果要让一个函数的代码完整地显示在IDE中，那最大代码行数不能超过50。

2、一行代码多长最合适

这个也没有一个完全的准侧，毕竟语言不同要求也是不同的

当然有个通用的原则：一行代码最长不能超过IDE显示的宽度。

太长了就不方便代码的阅读了

3、善用空行分割单元块

也就是垂直留白，不太建议我们的代码写下来，一个函数或方法中一行空格也没余，通常会根据不同的语义，一个小模块的内容完了，通过空白空格进行分割。

4、空⾏

1. 定义变量后要空⾏。尽可能在定义变量的同时初始化该变量，即遵循就近原则。如果变量的引⽤和定义相隔⽐较远，那么变量的初始化就很容易被忘记。若引⽤了未被初始化的变量，就会导致程序出错。
2. 每个函数定义结束之后都要加空⾏。
3. 两个相对独⽴的程序块、变量说明之后必须要加空⾏。⽐如上⾯⼏⾏代码完成的是⼀个功能，下⾯⼏⾏代码完成的是另⼀个功能，那么它们中间就要加空⾏。这样看起来更清晰。

成对书写

成对的符号⼀定要成对书写，如 ()、{}。不要写完左括号然后写内容最后再补右括号，这样很容易漏掉右括号，尤其是写嵌套程序的时候。

缩进

缩进是通过键盘上的 Tab 键实现的，缩进可以使程序更有层次感。原则是：如果地位相等，则不需要缩进；如果属于某⼀个代码的内部代码就需要缩进。

对齐

对齐主要是针对⼤括号{}说的：

1. {和}分别都要独占⼀⾏。互为⼀对的{和}要位于同⼀列，并且与引⽤它们的语句左对齐。
2. {}之内的代码要向内缩进⼀个 Tab，且同⼀地位的要左对齐，地位不同的继续缩进。

代码⾏

1. ⼀⾏代码只做⼀件事情，如只定义⼀个变量，或只写⼀条语句。这样的代码容易阅读，并且便于写注释。
2. if、else、for、while、do 等语句⾃占⼀⾏，执⾏语句不得紧跟其后。此外，⾮常重要的⼀点是，不论执⾏语句有多少⾏，就算只有⼀⾏也要加，并且遵循对齐的原则，这样可以防⽌书写失误。

二、冲刺任务

1、功能

• 完成用户登录，注册
• 完成主界面的主要功能
• 完成二手商品的发布，下架，购买
• 完成客户信息的修改
• 完成二手商品的搜索
• 完成二手商品的分类
• 完成二手商场的购物车

2、具体日程安排

时间区间	任务要求	完成状态
5.20-5.21	项目启动会议，编写代码规范	已完成
5.22-5.23	各项功能的初期	已完成
5.24-5.27	各项功能的编写，功能的基本实现	未完成
5.28-5.31	测试、找bug、调试软件	未完成