状态码分类
HTTP状态码分类
分类 分类描述
1** 信息,服务器收到请求,需要请求者继续执行操作
2** 成功,操作被成功接收并处理
3** 重定向,需要进一步的操作以完成请求
4** 客户端错误,请求包含语法错误或无法完成请求
5** 服务器错误,服务器在处理请求的过程中发生了错误
200 成功
10001 输入参数错误
10002 网络错误
10003 文件错误,请检查是否responseheader是否缺少Content-Length
10004 格式错误
10005 系统错误
401
500
403
302
-1 未知错误
$array=[
100 =>'继续',
101 =>'切换协议',
200 =>'OK',
201 =>'创建',
202 =>'接受',
203 =>'那些信息',
204 =>'没有内容',
205 =>'重置内容',
206 =>'的部分内容',
300 =>'多个选择',
301 =>'搬到永久',
302 =>'发现',
303 =>'看到其他的',
304 =>'不修改',
305 =>'使用代理',
306 =>'未使用',
307 =>'临时重定向',
400 =>'错误请求',
401 =>'未经授权的',
402 =>'付款要求',
403 =>'禁止',
404 =>'没有找到',
405 =>'方法不允许',
406 =>'不可接受的',
407 =>'代理身份验证要求',
408 =>'请求超时',
409 =>'冲突',
410 =>'消失',
411 =>'所需长度',
412 =>'失败的前提',
413 =>'请求实体太大',
414 =>'要求通用的时间太长',
415 =>'不支持的媒体类型',
416 =>'请求范围不可以满足的',
417 =>'期望失败',
500 =>'内部服务器错误',
501 =>'未实现',
502 =>'错误网关',
503 =>'服务不可用',
504 =>'网关超时',
505 =>'HTTP版本不支持',
];
代码规范
1.提高代码复用即, 个代码片段出现过多次,就可以考虑封装其为公共方法;
3. 接口除了域名外,路径写全,方便前端对接
4. 自定义类库统一放在根目录下的extend下面, composer类库放在vendor下面、自定义的函数放在common.php里面
5. 在引用模型或者其他类库的方法时,注释一下时干嘛的
类库引用规范
1. 自定义类库统一放在根目录下的extend下面, composer类库放在vendor下面、自定义的函数放在common.php里面
2. 在引用模型或者其他类库的方法时,注释一下时干嘛的
接口返回规范
1.{"code"="1","msg"="返回信息","data"="数据","time"="数据请求时间" }
2.code=1是成功,失败的自定义
命名规范
1. 采用驼峰法命名,同样的方法,命名为 getUserNarne()比命名为 getusernarne()更易于阅读、采用_命名或者首字母大写
2. 命名方式必须在整个项目中统一
3. 方法的作用都是执行一个动作,达到一个目的。所以名称应该说明方法是做什么的。一般名称的前缀都是有第一规律的,如is(判断)、get(得到),set(设置),del(删除),add(添加),edit(修改),show(展示),details(详情)、lists(列表)
代码注释规范
/**
* 测试方法
*
* @ApiTitle (方法名test)
* @ApiSummary (测试描述信息)
* @ApiAuthor (接口作者)
* @ApiMethod (POST)
* @ApiRoute (/api/demo/test/)
* @ApiHeaders (name=token, type=string, required=true, description="请求的Token")
* @ApiParams (name="id", type="integer", required=true, description="会员ID")
* @ApiParams (name="name", type="string", required=true, description="用户名")
* @ApiParams (name="data", type="object", sample="{'user_id':'int','user_name':'string','profile':{'email':'string','age':'integer'}}", description="扩展数据")
* @ApiReturnParams (name="code", type="integer", required=true, sample="0")
* @ApiReturnParams (name="msg", type="string", required=true, sample="返回成功")
* @ApiReturnParams (name="data", type="object", sample="{'user_id':'int','user_name':'string','profile':{'email':'string','age':'integer'}}", description="扩展数据返回")
* @ApiReturn ({
'code':'1',
'msg':'返回成功'
})
*/
public function test()
{
$this->success('返回成功', $this->request->param());
}
@abstract | 抽象类的变 和方法 | |
@access | public, private or protected | 文档的访问和使用权限。@ ccess private表明这个文档是私有的 |
@author | 小明 | 文档作者信息 |
@copyright | 名称时间 | 文档版权信息 |
@deprecated | Version | 文档中被废除的方法 |
@deprec | 同 @deprecated | |
@example | /path/to/example | 文挡的外部保存示例文件的位置 |
@exception | 文档中方法抛出的异常,也可参照@ hrows | |
@global | 类型 $globalvarname | 文档中的全局变量及有关的方法和函数 |
@ignore | 忽略文档中指定的关键字 | |
@internal | 开发团队内部信息 | |
@link | URL | 类似于lic se ,但还可以通过访问 地址找到文档中更多的详细信息 |
@name | 变量别名 | 为某个变量指定别名 |
@magic | PHPDoc兼容phpDocumentor的标签 | |
@package | 封装包的名称 | 一组相关类、函数封装的包名称 |
@param | usemame 用户名 | 输入变量含义注释 |
@return | 如返回bool | 输出函数返回结果描述,一般不用在vo id 空返回结果的〕的函数中 |
@see | Class Login() | 文件关联的任何元素(全局变量,包括页面、类、函数、定义、方法、变量〉 |
@since | version | 记录什么时候对文档的哪些部分进行了更改 |
@static | 记录静态类、方法 | |
@staticvar | 在类、函数中使用的静态变量 | |
@subpackage | 子版本 | |
@throws | 抛出的异常 | |
@todo | 表示文件未完成或者要完善的地方 |
PHP语言本身的语法比较松散,稍不留神,平时编码的时候就有可能写出“异形”代码,这无形中提高了对开发者的要求。所以在正式编程之前,一定要打好PHP语言基础,仔细阅读编码规范,同时学习其他项目中的优秀代码。在编码的同时,需要注意以下几点
1.规范注释
良好的注释习惯,不仅可以让别人更容易读懂你的代码,也避免出现“这是我写的代码么?”这样的疑问。代码注释的风格因人而异,但只要结构合理、通俗易懂即可满足要求
除了开发团队编码规范要求外,注释一殷可以分为文件注释、类注释和方法注释3种这里参考 PHPDOC的注释规范,它是一种注释PHP代码的正式标准,在IDE中提供代码完成、类型提示和除错功能,而且支持面向对象和面向过程的不同代码风格
下面是一个典型的带有PHP注释的用户类(User)
从实例中可以看出,无论是类注释,还是方法注释 都使用了类似“@标签名 说明
内容”的方式,对注释进行描述, 多个标签描述行组成了注释块。 而这样的标签还有很多,
开发者使用的时候可 灵活搭配。 PHPDoc 提供的常见注释标签说明如表 示。
2.善于代码重构
很多代码在初次编写的时候,虽然可以正常运行,但可能会因为程序设计不完善或交付时间短等各种原因,导致性能低下和难以阅读等问题。这时候就需要对这一部分代码进行重构操作。
重构代码一般应满足以下几个目的
- 改善程序设计,提高灵活性
- 增强代码阅读性,使代码更易理解
- 提高性能,不仅程序运行更快,编写也更快
- 减少已知和未知的BUG。
在重构代码的时候,可以着重注意以下几个方法
- 提高代码复用即,一个代码片段出现过多次,就可以考虑封装其为公共方法 采用驼峰法命名即,同样的方法,命名为 get
- Username(比命名为a0更易于阅读(注意方法依赖)
提示:一定不要为了重构代码而重构代码,具体问题具体分析。代码重构可以说是一门艺术,这里推荐大家阅读《重构:改善既有代码的设计》一书
3.文档编写
在阅读文档和编写代码的时候,也可以自己积累笔记和文档。除了记录项目的开发配置、版本库地址等必备信息外,还需要把常见问题和经验记录下来,这样下次再遇到相同的问题时就不用重复寻找解决方案了常用的笔记软件