编写优雅Python代码的16个原则
假如你刚参与了⼀个算法项⽬，当你第⼀次打开这个项⽬时，发现⾥⾯已经有上万⾏与算法相关的代码，仔细查看过后，发现如下⼀些让你抓狂的问题：
1 、代码写的⾮常冗余，维护已经变得越来越困难。
2 、⼏乎没有任何注释。
3 、⾮常错乱的代码风格，让你有⼀种感觉打开了⼀个杂乱的⽹站的 html 页⾯。
4 、存在那么⼏个函数，单个函数的源码超过 500 ⾏。
5 、每⼀次需求的变更，都意味着⼀次痛苦的代码编写。
这是 笔者 以前参与⼀个算法项⽬时遇到的问题。
在参与这个项⽬时，⼤家都在很努⼒的使项⽬往期望的⽅向⾛，但随着开发进度的往前推进，项⽬的复杂性正在不断加⼤，⼤家都在尽可能使⽤⾃⼰了解的最好的技术将系统打造的更为强壮，但系统但复杂性⼀点也没有降低。在需求但不断变化中，代码的冗余也越来越明显。程序中到处充斥着废弃的代码，但谁也不敢轻易去删除，谁也不清楚⾃⼰的⼀个不经意操作，是否会导致整个程序的奔溃。
对于代码的开发，⾥⾯包含了很多细枝末节的东西，特别对于需要⾼度配合的项⽬（如算法⼈员和⼯程⼈员之间），细节的处理是否妥当，将很⼤程度影响项⽬是否可以成功交付，跨⾏之间的配合与细节的处理是⼤部分开发者所⽋缺的，这类⼈才也是市场上急需的。
python 的设计宗旨是简单、优雅、明确。
但很多开发⼈员通过⾃⼰的努⼒将其做成了复杂、丑陋、晦涩。
结合 Python 之禅与⾃⼰的开发经验，给出如下⼀些观点与建议，希望可以为你带来⼀些帮助：
0 1
优美胜于丑陋
代码除了完成指定功能，同时也是给⼈看的。优美的代码和优美的风景⼀样，都能让⼈感到赏⼼悦⽬，优美的代码是⼀种艺术，相对于丑陋的代码，⼤家都会倾向于查阅优美的代码。
在⼯作过程中，尽可能往编写优美代码的⽅向⾛。
0 2
明了胜于晦涩
在代码编写中使⽤明了的词语来命名⽅法名、函数名或变量名是⾮常好的习惯。命名很好的代码，可以省略很多代码注释的⼯作，优秀的代码会说话。
编写优秀的代码，代码本⾝就是注释。
最好的代码是不需要注释就可以让⼤部分⼈都可以看懂，这需要编写者有很强的编码功底和语⾔抽象功能，很多时候并不要求所有开发这都有这种能⼒，但也需要在少量的代码注释情形下可以让代码阅读者可以快速看明⽩你写的代码。
如果可能，尽量减少晦涩代码的出现，⼤部分情形下，晦涩代码的出现都是因为开发者对需求了解不清楚或没有⽤更简单的⽅式思考，对于代码的负责⼈，若看到出现类似代码，应当⼩⼼谨慎，需要了解对应的需求是否确实会如代码那么晦涩，还是开发⼈员想复杂了。
0 3
简单胜于复杂
把简单的事情做复杂并不难，但要把复杂的变得简单，那需要付出巨⼤的艰⾟。
在⼯程应⽤中，把简单的需求做得复杂的案例数不胜数；⽽能通过抽丝剥茧的⽅式把复杂应⽤场景拆分的很简单的案例少之⼜少，当今市场极为缺乏有这种能⼒的⼈才。
复杂的来源也是有很多当时以为简单的事情堆积⽽成的，在多种简单的组合过程中，继续保持整体的简单，是⼀件值得思考的事情，这要求在对整体了解的情况下对各个细节的把控，编程本来就是⼀门对细节要求极⾼的技术，当对细节的掌控了然于胸时，编写出简单的代码就⽔到渠成了。
0 4
复杂胜于凌乱
我们排斥复杂，但有时复杂难以避免。可以复杂，但不要凌乱。有迹可循的复杂代码还是具有可读性的，⾄少可以从代码层⾯到处理逻辑。
当代码以凌乱的⽅式出现时，那是会让⼈⾮常崩溃的。犹如你与⼈交谈时，若与你谈话的⼈⼀直东⼀句，西⼀句，让你根本不清楚对⽅在讲什么，估计你与对⽅聊上⼏分钟就不想聊了，并期望不想再遇到类似的聊天对象。编程也⼀样，对于那些凌乱的代码，⼤家都是避之不恐。
0 5
扁平胜于嵌套
在编写代码时，每增加⼀个嵌套，则意味着代码的复杂度增加了⼀些，代码的执⾏效率对应的下降了⼀些。
当出现三层以上的嵌套时，那说明代码编写思路出现了偏差，对于这种代码，应该会⾮常浪费系统的资源，甚⾄全部耗尽。实际应⽤中应当避免，并寻求其它更简单的实现⽅式。
能⽤扁平的⽅式实现时，就不要使⽤嵌套实现。
0 6
间隔胜于紧凑
若是⾯向计算机编程，代码间隔紧凑与否是没有任何关系的。但若需要不断被开发⼈员查看，适当的间隔那就⾮常有必要了，组织良好的代码不仅仅是逻辑清晰，在代码结构上也是⾮常有讲究的，很多时候都会遵循 PEP8 的规范，那样写出来的代码是让⼈赏⼼悦⽬的。
另⼀⽅⾯，这也能帮助你编写出更加⾼效的代码，因为通过合理的控制代码结构，当程序发⽣问题时，组织良好的代码结构可以帮助你更快的到问题。
0 7
可读性很重要
很多时候，我们编写的代码除了让计算机执⾏指定的程序，另⼀个很重要的点就是给其他⼈查看。⽽代码的可读性决定了会有多少⼈愿意读你的代码。python新手代码错了应该怎么改
现在很流⾏的⼀个词叫开源代码，对于开源代码，可读性在很⼤程度上决定了有多⼈愿意参与到这个开源中。
⽽对于项⽬应⽤中，编写⼀份可读性⾮常⾼的代码是⾮常必要的，尽管很多时候是以功能优先。提⾼代码的可读性，不仅仅是⼀个⾃我的修炼过程，对于团队、甚⾄公司，都可以更好的减少开发、维护和学习成本的。
0 8
特例不⾜以特殊到违背这些原则
在代码编写过程中，不可避免会需要对某些特例提供⽀持，甚⾄有时为了可以⽀持特例，需要违背⼀些已有的好的原则。
当有需要类似的操作时，需要做更为全局的平衡，这个特例是否必须，是否有其它可处理⽅式，怎么最⼩化特例给其它原则带来的破坏。
0 9
实⽤性胜过纯粹
编写代码的⾸要原则是可⽤，在可⽤的基础上才有可能执⾏其它如性能优化、效率提升等操作。
实⽤性与纯粹性不同，纯粹性更多体现在实验或验证性操作上，很少参与到真实环境中的应⽤，⽽我们需要的是可以在真实环境中可⽤的代码。
0 10
永远不要默默地忽视错误
当程序出现错误时，那已经在提⽰我们程序中的某处代码并没有如我们想象的那么完美，它编写有 Bug 或是有隐藏 Bug ，需要我们进⾏正确的处理，若置之不理，很有可能埋下⼀颗定时，在某⼀刻让你的程序直接崩溃，这种的代价往往都会不⼩。
在实际的应⽤中，即时是很⼩的问题，也不要选择忽视，建⽴起必要的异常管理，⽽不要等到问题发⽣时才进⾏亡⽺补牢的操作，殊不知可能会为时已晚。
0 11
⾯对模棱两可，拒绝猜测
计算机的世界是 0 或 1 的世界，是即是，⾮即⾮，没有不确定性的存在，也没有任何的猜测。
对于编写的任何代码，都应该是清晰的，没有歧义的，若出现有歧义或不清晰的情形，那表明开发者对需要通过代码实现的问题理解不到位，或是有猜测的成分，这种都是需要杜绝的。
0 12
解决问题最直接的⽅法应该有⼀种，最好只有⼀种
在编程的世界⾥，任何问题的解决办法都有多种，但更多的时候我们需要的是最直接的⽅法，并最好只有⼀种最直接的⽅法。
如对编程语⾔的选择，对于科学计算和⼈⼯智能相关的事情，最直接的选择就是使⽤ Python ，这个对于⽬前来说是最直接的唯⼀选择。
0 13
做也许好过不做，但不想就做，还不如不做
对于编程的过程，是⼀种知⾏合⼀的过程，光靠执⾏很多时候并不能得到期望的结果，还需要伴随思考的过程。越是⼤的项⽬，前期思考的时间占⽐就越多。在动⼿之前先做⼀些计划，对全盘先有⼀个⼤致了解，把可能遇到的问题，会存在的瓶颈，会占⽤时间⽐较多的步骤，需要协助的资源等先做⼀个前期的规划，会⾮常有利于后期的执⾏的。
若期望⼀开始就撸起袖⼦直接⼲，那不是⼀个很建议的⽅法，除⾮你对需要做的事情已经⾮常熟悉，否则还是有必要认认真真想⼀想需要做什么。
0 14
如果⽅案难以描述明⽩，那么⼀定是个糟糕的⽅案
对于编程来说，编写的应该是⼀个确定的事情，并且已经有可以描述明⽩的⽅案。
对于不清晰的⽅案，编程上更不可能清晰。
⼀个糟糕的⽅案只会诞⽣⼀个糟糕的项⽬，项⽬⾥⾯则包含各种晦涩的代码。
0 15
如果实现容易描述，那可能是个好⽅案
若⼀个实现可以通过类似伪代码的⽅式描述出来，这基本上是⼀个可⾏的⽅案，若可以通过伪代码容易的描述，那很有可能是个好⽅案，真实的应⽤上还有很多其它的外界因素，只有结合那些因素，才能完全的确定这是否是⼀个好的⽅案。
0 16
命名空间是⼀种绝妙的理念，多加利⽤
在编码的过程中，命名的冲突是⼀个⾮常需要⼩⼼的问题，这种问题⼀般不容易发现，出现问题时的查并不容易，所以需要充分借助命名空间的理念，尽量避免如命名冲突的问题。
通过命名空间控制变量的作⽤域，可以起到很好的变量的相互隔离的效果。
结语：
编码是⼀件快乐的事情，特别当看到⼀些貌似不太可⾏的事情，通过编程的⽅式变为可⾏时，会感到⼀种发⾃内⼼深处的快乐。并且当⼀⼈通过策之⼒，完成⼀件艰巨的任务时，创造出⼀些 amazing 的事情时，那是⼀种不可⾔喻的喜悦。
⽽编写出如艺术般的代码需要付出很多，也需要经过时间的锤炼，但当它出现在⼤家眼前时，是需要
⼀种⼼境的追求才可以企及，任何⼈都可以往这个⽅向追求，它没有任何标准，没有任何约束，有的只是你的不断创造，在计算机编程这块沃⼟上，还有⼀个超⼤的空间等待更多的⼈去开拓。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。