随着产品版本迭代和日渐丰富的功能，源文件及代码也愈发庞大和复杂，对于程序开发人员来说，除了保障程序运行的正确性及提升代码运行的性能和效率之外，一套优雅统一的编码规范会对项目的更新、修改、维护等带来极大的便捷性，也能是程序免于陷入不同风格代码理解的泥潭中而无法自拔(编码规范的必要性可参考谷歌前计算机科学家 Mark Chu-Carroll的一篇短文，有兴趣可以点击去接受一次喷洗^-^ . http://goodmath.scientopia.org/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/此处不过多深入)。结合过往多年的工作经验，笔者下文从Python编码规范、URL设计规范、程序设计常见注意事项三个方面进行了简单阐述。
一、 Python编码规范
Python编码规范此处主要结合日常开发项目情况，根据常用的PEP8规范做了部分筛选和小结：
1. 代码布局
- 缩进：四个空格；
- 空格or tab的选择：用空格，在IDE中自动使用空格作为换行，如果自己在vim中编辑时，要用空格，保持一致；
- 最大行宽：所有行的最大行宽为79个字符，如果是文本（如注释）最大为72字符；
- 空行：全局函数之间、类定义之间空两行；成员方法之间空一行；
- 标准库或者普通库的导入：
① 导入一个库在单独行；
② 导入始终在文件的顶部，在模块注释和文档字符串之后，在模块全局变量和常量之前；
③ 导入顺序：标准库,第三方库，本地库。导入之间要有空行；
④ 尽量使用绝对路径导入。
2. 表达式和语句中的空格
- 总体原则，避免不必要的空格；
- 各种右括号前不要加空格；
- 逗号、冒号、分号前不要加空格；
- 函数的左括号前不要加空格，如Func(1)；
- 序列的左括号前不要加空格，如list[2]；
- 操作符左右各加一个空格，不要为了对齐增加空格；
- 函数默认参数使用的赋值符左右省略空格；
- 不要将多句语句写在同一行，尽管使用‘；’允许；
- if/for/while语句中，即使执行语句只有一句，也必须另起一行。
3. 注释
- 在更新代码时，优先更新注释，不对应的注释比没注释还要糟糕；
- 类定义时需要说明类的用途；
- 除少部分无歧义方法（如__init__）外，一般函数方法需要说明函数的具体作用，函数的输入参数，返回值类型及格式。
4. 命名约定
- 前面有单下划线：1.弱内部标志：from M import不会导入的对象；
- 后面有单下划线：1.避免与关键字冲突；
- 前面有双下划线：1.对类这样命名的时候，会触发名字重整；
- 避免使用的名字：1.'i',小写i；2.'I',大写i；3.'O',大写o；
- 模块名、包名：模块名全部小写，用下划线连接；包名也是小写，但是不用下划线；
- 类名：CapWord命名，也就是pascal风格，首字母大写；
- 异常名：在类名后添加Error；
- 全局变量名：变量尽量只用于模块内部，约定类似函数。对设计为通过 "from M import " 来使用的模块，应采用 all 机制来防止导入全局变量；或者为全局变量加一个前置下划线；
- 函数名：小写，必要时添加下划线；
- 函数和方法参数：实例方法第一个参数是 'self'。类方法第一个参数是 'cls'；
- 常量命名：大写字母加下划线；
- 继承命名：公开属性应该没有前导下划线；
- 如果公开属性名和保留关键字冲突，可以添加后置下划线；
- 简单的公开数据属性，最好只公开属性名，没有复杂的访问/修改方法，python的Property提供了很好的封装方法。 d.如果不希望子类使用的属性，考虑用两个前置下划线(没有后置下划线)命名。
5 编程中的建议
- none值比较尽量用is，is not 而不是用==；
- 异常类继承自Exception，而不是BaseException；
- Python2中用"raise ValueError('message')"代替"raiseValueError, 'message'"；
- 捕获异常时尽量指明具体异常，而不是空"except:"子句；
- 函数或者方法在没有返回时要明确返回None；
- 使用字符串方法而不是string模块；
- 使用.startswith()和.endswith()代替字符串切片来检查前缀和后缀；
- 使用isinstance()代替对象类型的比较：
- 对序列(字符串、列表 、元组),空序列为false:
- 字符串后面不要有大量拖尾空格；
- 不要用== 进行布尔比较
二、设计URL应该遵循的原则
1、简单，好记
简单好记的域名会给人以深刻的印象。
2、URL中的字母全部用小写
全部用小写，用户比较容易输入，不用因为大小写混合而出现错误，这是人们的输入习惯，有些服务器是区分大小写的，例如Lunix服务器，这样在站长做链接或者是用户输入时，会因为大小写的问题而出现404错误，而且robots也是区分大小写的，如果大小写搞错了，可能会造成不能收录的严重问题。所以建议所有的URL都使用小写。
3、连词符的使用
目录或者文件名中如果有两个单词组成时，一般建议中间使用中划线(-)隔开，切记不要使用下划线或者其他字符，在搜索引擎中，它是把中划线当作一个空格来处理的，而下划线则是被忽略的，例如seo-caipiao会被读成seo与caipiao。这是比较友好的写法。
4、URL中避免太多参数
设计的则是URL中的参数应该尽量减少，不要超过三个，一般的情况下URL中的参数2-3个就可以了。
5、目录层次尽量少
这里所指的目录层次是指物理目录结构，而不是指逻辑结构，我们在进行URL的设计时，网站的结构要尽量的去减少目录层次，层次不能太深了，一般建议不要超过三层，特别对于一些新站来说，权重低，搜索引擎蜘蛛爬行得很浅，深一点的页面，蜘蛛都很可能不会去爬行的，所以要尽量的做到使目录层次减少，URL缩短。根据观察，百度尤其比较喜欢目录层次比较少的页面。
6、文件名及目录名要具描述性
文件名及目录名要具有可描述性，不但让用户一眼就能看出来这个页面是关于什么的，对用户体验比较友好，而且搜索引擎也比较喜欢这样的URL。
例如一个关于新闻的目录，我们可以把它命名为news，用户看到这个目录名称，大概就知道这个目录是关于什么内容的了。
7、URL应该呈现一个降级的次序
例如：域名/类型/分类/标题
例如：域名/年/月/日
http://domain.com/news/tech/2007/11/05/google-announces-android
三、程序设计注意事项：
1. 时效和性能
1.1 循环使用
在程序设计及功能实现的过程中，很多时候我们需要用到循环来是完成特定的业务需求，相应的在某些情况下该部分则可能引起该接口的性能问题；
在选择循环设计的过程中，需要注意一些事项：
- 循环体中是否有db操作，http,tcp请求操作等和网络相关的耗时行为，若有，则尽量避免使用循环，使用其他替代方式实现相应功能；
如：查询近期三十天内每日数据统计情况；
原始方式：
优化后：
- 需要插入大量多数据，尽量采用批量插入方式，避免使用循环；
如：
- 当某些情况下不得不使用循环，同时循环体中又不可避免有耗时的操作，如复杂算法计算等，此时可采取多线程/多进程/微服务/异步回调等方式。
1.2 递归使用
递归用法有些时候确实可能比较方便的实现一些特殊的业务逻辑，但同时随之而来的也带来了一些新的风险：无限递归, 由于代码设计的不合理或者一些特殊情况的出现很有可能导致递归程序结束条件无法生效，难以跳出递归，程序彻底卡死或者延迟严重。
当必须使用递归用法时，有必要预估递归的极限次数，做好相应的防范错误，如当递归到一定次数阈值时，强制跳出递归，输出错误日志。
2. 耦合性
程序开发过程中，代码各模块之间的耦合性高低很多时候将决定着代码质量的好坏以及后续维护和扩展的易用性；在日常架构设计时，我们需要尽量去解耦不同的功能和逻辑模块，最大程度降低相互之间的直接依赖性；不同模块间互相不关注其内部细节，定义好接口后自身封装相应内部逻辑，无论内部如何变化使其不影响其他模块的外部调用者。
如笔者当前一个小项目中所使用的架构：
3. 扩展性
代码的低耦合性很大程度上也决定了程序后续的可扩展性；与此同时，在我们进行功能实现和架构设计时，或许可以更多的思考下当下的这部分功能是否可以为以后其他类似的项目和业务复用，如tcp通信时该部分代码如何设计封装以使之后所有其他需要用到tcp传输的项目可以直接移植使用或者做尽量少的改变，又如hbase,mysql,mongo等等数据库的存取，在实现设计之初，尽量多考虑些后续代码的复用和灵活扩展，在项目时间较为紧急的情况下，如果来不及进行比较好的封装，那就退而求其次，通过适当的封装内聚为以后的优化埋下伏笔，做好预备工作。
如代码中各种静态配置信息，常量定义，数据表名称等等，可以将相应信息抽取到同一个配置文件或头文件中，真正做到一处修改多处生效，提高不同环境下代码的复用性，同时也避免各配置变更后某处引用未修改的而产生的不一致性问题。
4. 内存管理
5. 多线程/多进程/线程安全/可重入
6. 可靠性/便于运维p
后期待续ing ...
