编写Python代码时最好遵循的一些规则
参考来源：
https://www.ndepend.com/default-rules/NDepend-Rules-Explorer.html?ruleid=ND1000#!
欢迎讨论交流，如有侵权请联系本人！
-
限制类内代码长度
类的代码长度最好不要超过200行（仅包括直接写在类内的代码，且不含注释所占的代码长度）。大多数情况下，过长的代码意味着逻辑混乱和功能杂糅，因此会导致后续的开发和维护难度的增加。代码过长的类通常会拥有过多的成员变量和（或）函数，这也会使得代码的阅读和理解变得困难。更为严重的是，类代码过多意味着许多和类本身弱耦合的方法也被放到类的内部，这对于程序的逻辑完整性和自洽性是较为严重的破坏，而且也会使得后续改造、拓展和兼容变的十分麻烦。
改正方法：
重构代码过长的类，一般来说，不合规的类会被拆分成多个平行的类或嵌套的类，有时候也会将类中的低耦合度函数放到类的外部。关于类的重构，我们有以下几个简单的建议：
- 类中相对独立的部分可以分离出来并重构为一个（私有）类，这样可以在当前类中嵌套使用这些功能完整的独立的类，以达到减少单一类中代码量的目标。
- 当一个类中的方法不涉及到类或类的实例的数据成员，那么一般情况下，这个方法会用修饰符
@staticmethod修饰为静态方法。但如果一个静态方法仅供内部使用，并且不希望此方法被外部调用，那么这个静态方法应当被移到类的外面并声明为模块私有函数。 - 在重构的过程中，最好事先写好模块测试代码，并且尽量保持重构后的类外部接口不变。这样在重构完成后，可以快速测试重构的代码是否功能正确。
-
限制类方法的数量
类的方法最好不超过20个，否则同样会导致难以理解和维护（不包括以双下划线开头结尾的魔术方法）。
改正方法：
重构方法过多的类，具体参见上一问题。
-
限制类数据成员的数量
类的数据成员最好不要超过15个。
改正方法：
- 检查是否有不必要的数据成员，例如：仅在初始化的时候使用一次，之后不会再用到的数据成员；可以由其他的数据成员简单推算出来的数据成员。在不影响代码阅读和维护的情况下，应当尽量删除这些不必要的数据成员。
- 封装一组类似或相关的数据成员。可以用内部数据结构（比如说字典）封装，也可以用一个新的类封装。
-
限制类方法的代码长度
方法的代码最好不要超过35行（不包括代码的折行，空行以及注释所占的行数）。一个方法最好只讲述一件事情，完成一个功能，并且应当用尽量少的逻辑嵌套结构，多个方法（函数）互相调用的理解难度一般来说要远小于单一的长方法（函数）的理解难度。
改正方法：
- Python有许多高级的语法可以简化操作逻辑的描述，使用这些高级语法可以大量缩减代码的行数，不过最好不要以牺牲代码的可读性为代价强行使用高级语法。
- 将方法拆分为多个方法，或者将方法内部相对独立的部分拆分成新的方法，并在本方法内部调用。方法的使用不仅仅是为了提高代码的复用程度，也是为了让代码能够更加的模块化，从而减少编程过程中以及阅读和维护代码时遇到的困难。
-
限制方法的参数数量
方法的参数一般不超过6个，过多的参数会使得记忆难度增加，从而导致阅读和维护变得困难。
改正方法：
与类的数据成员过多的问题的解决方法相似。或者也可以使用解析的方式解析用户输入的参数，并在注释中标明含义和使用方法。
-
避免方法缺少注释或者注释不充分
方法注释的代码占比不应小于10%。如果方法总体代码不足20行，那么方法的注释比例一般要更高。一般来说，命名良好，逻辑清晰，行文优雅的代码能够让人在缺少注释的情况下同样能够快速理解代码，但是注释仍然有利于代码编写时理清自己的逻辑，并且能够加块维护人员理解的速度。在代码中使用了特殊的方法，或者针对某一特殊问题作出优化时，注释则变得非常必要，否则很有可能使后续的维护变的极为困难。对于方法参数和功能的注释可以使调用者在不必通读代码的情况下，就能够轻松使用方法，在这一层面上，注释也是十分必要的。
改正方法：
- 使用Pylint检查代码。Pylint会提示编写者在合适的地方添加注释。如果编写者使用reStructuredText格式编写注释，那么Sphinx可以帮助编写者自动生成代码的文档。
-
限制方法内部局部变量的数量
方法的局部变量一般不超过15个，包括函数参数变量。8个以上的局部变量就会使代码的阅读变的困难，而局部变量超过15个会使得代码过于复杂，这种情况下方法最好重构。但一般来说，大型算法的实现过程中，有很多函数都需要用到大量的中间变量，如果为了追求局部变量的数量限制，而使用了许多重复的变量名，就变成了舍本逐末，得不偿失了。
改正方法：
可以结合使用局部变量封装和方法分解重构的方法避免这一问题的发生。这两种方法的具体步骤本文中均有所描述，此处不再赘述。