Lonersun

您看看这篇文章，不知能不能解答一些你的问题 https://juejin.im/post/6844903817192947726

@ly4572615 @opengps 实际场景：我们这用的是 mac 系统的 Page，在打开 word 文档时是好几段叠在了一起，而且不是个例，碰到过至少十几次，每天要筛好多简历，基本上碰到这样的就直接过了

您可以参考下 git flow 的流程 https://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html

@laike9m 对，写错了

@laike9m 第一个问题：我们在做一些复杂逻辑处理的时候，增加必要的空行会让代码读起来更清晰些吧，比如下单接口，第一进行库存处理，第二下单处理，第三扣款处理，如果三块没有空行对读代码的人可能不太友好，当然这种复杂类的还是要拆方法；

第二 中文前加 u, 我没有注明是 python2，python3 已经不需了，目前我们还是 python2，编码问题还是比较累

第三条，我写的不太明确

错误：
def test():
# 测试方法

正确：
def test():
"""测试方法"""

感觉这种方法的注释，Numpy 这个包的开发者写的注释非常好

非常感谢您指出的问题

@xiangyuecn 简单的、一次性的项目没有那么多框框，但是针对一些比较中大型的项目，一些规范还是必要的，否则后期维护简直是灾难，就我们现在的项目开发维护了两年，大大小小迭代了十几个版本，研发前前后后小二十人，如果没有规范，维护起来还是很难的，而且好多规范不同语言之间道理是相同的，在看 JAVA 规范的时候发现好多可以借鉴的地方

@renmu123 @aeron 我们团队内部也是要求必须遵守 PEP8 编码规范，而我们这个规则是在 PEP8 规范上的补充，更多的偏向业务方向以及一些小的技巧，目的是为了让大家风格保持一致，提高代码的可读性

@laike9m 多谢指正

@PbCopy111 一部分是自己在实际项目中的经验教训，一部分是参考了大家约定俗称的东西，也参考了阿里 JAVA 编码规范的一些东西，我个人认为编码规范没有对错之分，这更像一个契约，一个自己团队能保持风格一致的规则，如果有利于代码维护，那目的就达到了。