Python 代码风格

前端之家收集整理的这篇文章主要介绍了Python 代码风格前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

<h3 style="text-indent: 27.1pt">
<span lang="EN-US">1 原则
<p style="text-indent: 24.0pt">在开始讨论<span lang="EN-US">Python社区所采用的具体标准或是由其他人推荐的建议之前,考虑一些总体原则非常重要。


<p style="text-indent: 24.0pt">请记住可读性标准的目标是提升可读性。这些规则存在的目的就是为了帮助人读写代码,而不是相反。


<p style="text-indent: 24.0pt">本小节讨论你所需记住的一些原则。


<h4 style="text-indent: 28.1pt">
<span lang="EN-US">1.1 <span style="font-family: 宋体">假定你的代码需要维护

添加一部分或对其维护。这是由于很难预料到未来的需求,以及低估自己造成的倾向。然而,所写代码很少不被修改一直存在。

代码会一劳永逸的无需之后进行阅读、调试或修补,那么你就会非常容易陷入忽视其他可读性原则的境地,这仅仅是因为你相信这次并不重要

代码无需维护的直觉的不信任才是上策。稳赚不赔的办法是赌自己将会再次见到自己写的代码。即使你不维护,那也需要其他人维护。

代码风格和代码结构层面来讲,代码都要尽量满足内部一致性。无论是哪种格式化规则,代码风格都要贯穿项目保持一致。代码结构的一致性也就是同样类型的代码放到一起。这样项目容易把控。

代码的结构与其他人保持一致,如果一个新来的开发人员打开你的项目,你不应该让他的反应是:我从来没见过像这样的东 西。社区指导原则很重要,因为这就是开发人员加入到你的项目预期所见。类似的,以及相同的原因,请认真看待在使用特定框架时完成任务以及组织代码所采用 的标准。

)的主要意思就是关于存在的研究。在哲学上(在该领域这个词很常用)存在论是关于现实与存在本质的研究,是形而上学的子集。

事物在程序中如何存在。你如何将概念转化为在数据库中表示?亦或是用类结构表示?

代码的方式。是否使用继承或是组合来组织两个类之间的关系?数据库中用哪个表完成这项功能或是这个列属于谁?

在写代码之前先思考。尤其是思考程序希望实现的目标,以及程序之间如何交互。程序是一个对象与数据交互的世界。那么,它们之间协作所需遵循的规则是什么?

代码时,请考虑随着时间重复使用的值将会变更的情况。该值是否被用于多个模块或函数中?如果必要,需要花费多大代价修改它?

函数。你是否在程序中有大量的重复的代码?如果这些重复代码行数较多,可以考虑将其抽象到一个函数中,如果出现修改代码的需求,则更容易管理。

如果需要变更该代码,变更该代码的所有位置所需要的成本是多少

代码是一个故事。它是所发生故事的说明,在用户与程序交互过程中,从开始到结束。程序从某一点开始(可能带有一些输入),沿着一系列选择自己的冒险故事步骤到达终点,并结束(很可能带有一些输出结果)。

代码之前就添加一段注释,用于解释代码功能。如果代码是一个故事,那么注释就是故事的解释与旁白。

代码(例如,当尝试解决问题或维护代码时),然后可以从零开始快速了解所需维护的代码,这样就可以专注于代码本身所代表的意义。

代码意图。它可以回答这样的问题:写这段代码的人希望完成的目标是什么?偶尔,还可以帮助回答问题:为什么以这种方式完成工作?这些问题是在你阅读代码时很自然会问的,为这些问题提供答案将会帮助了解这些内容

代码中不显而易见或复杂部分的原理。如果使用了有点复杂的算法,请考虑将指向解释模式文章链接以及其他使用示例加入注释。

代码最重要的原则通俗来讲就是奥卡姆剃刀原则:最简单的解决方案通常是最好的。在他的之禅博文 (),该页面是编程格言的集合(例如,在控制台中输入就可以看到这篇),包括了类似下面这句如果你无法向人描述你的方案,那肯定不是一个好方案

代码如何运行与代码外观层面都生效。当提到代码运行时,简单的系统更加容易维护。实现的简单化意味着更少引入复杂的,哪些维护你代码的人(包括你自己)更容易凭直觉理解代码所代表的含义,并在不踩坑的前提下为程序增加代码

代码的外观,请记住,尽可能使得阅读代码就好像是在了解代码所做工作的故事,而不是为了解析词汇。词汇是手段,而故事才是最终目的。写一条诸如不要使 用三元运算符很容易。然而仅仅是遵循这些规则(虽然有价值)并不是代码明晰的充分条件。请专注以尽可能简洁的方式编写和组织代码

标准

社区大部分遵循所谓的)指导原则,由之父)编写并被包括标准库中的大多数主流项目采用。

的普遍性是其强大的原因之一。该标准被大多数社区项目采纳,因此你可以预计大多数你遇到的代码都遵循该标准。当你以这种方式编写代码时,代码会更加容易阅读,也更容易编写。

中的指导原则都很简单明了。部分重点如下:

使用个空格缩进。不要使用制表符()。

变量应该使用下划线连接,不使用骆驼式命名风格(使用而不是)。类名称以字母开头就是骆驼式命名风格(例如:)。

如果一个变量的用处是:仅内部使用,在变量名称之前加上下划线。

在运算符前后加上单空格(例如,,不是),也包含赋值运算符(而不是),只有在关键字参数情况下不适用,在这种情况下,空格可以省略。

在列表和字典中省略不必要的括号,(例如:而不是)。请阅读代码风格指南获得更多示例以及有关这些规则的更多讨论。

中,如果在一个函数或类中第一个语句是一个字符串,该字符串会自动赋值给一个特殊的变量,该变量在调用(和一些其他的类)时会被使用。

规定文档字符串(该名称可以被望文生义)是必须的。

函数体之前加空行。如果文档字符串有多行,则将结束的双引号单独放一行。

规定最高级的类和函数定义之间有两个空行。

<span style="color: #0000ff">class<span style="color: #000000"> B(object):
<span style="color: #0000ff">pass

代码清单

还规定除了最高级之外,类和函数的定义以一个空行分隔。

<span style="color: #0000ff">def<span style="color: #000000"> foo(self):

<span style="color: #0000ff">pass

<span style="color: #0000ff">def<span style="color: #000000"> bar(self):

<span style="color: #0000ff">pass

代码清单

函数或其他代码段中使用单空行分隔逻辑段是合理的。请考虑在逻辑段之前使用注释解释代码段的作用。

允许绝对路径导入和相对路径导入。在中,解释器会尝试相对导入,如果找不到路径,然后再尝试使用绝对导入。

中,使用特殊语法标记相对当如以()开头正常的导入方式只会尝试相对路径。的语法在以后版本可以使用。除此之外你可以使用关闭隐式相对路径导入。

绝对路径导入。如果不得不使用相对路径,请使用显式导入风格。如果你为编写代码,请考虑选择中的显式风格。

sys

代码清单

名称,当然可以将这些名称分组到一行中。

datetime date,datetime,timedelta

<p style="text-indent: 24.0pt">代码清单<span lang="EN-US">4


<p style="text-indent: 24.0pt">除此之外,虽然<span lang="EN-US">PEP 8并没有强制要求,考虑以包来源的方式将导入分组。对于每一组,按照字母表顺序排序。


<p style="text-indent: 24.0pt">另外,在导入时,请不要忘了使用<span lang="EN-US">as关键字给导入的内容起别名。


<div class="cnblogs_code">

 foo.bar  really_long_name as name

代码清单

名称或不规范命名的名称

名称无论何种原因不规范时,别名就很有价值了。

名称,如果没必要使用别名,这会使得代码变得不清晰。无论是使用何种工具,要做到具体情况,具体分析。

名称使用下划线连接,而不要使用骆驼代码风格(例如,而不是)。除此之外,起一个具有描述性的名称同样重要。

名称并不合适,虽然某些情况下这么做也能接受,比如在循环中的变量(例如,)。

函数名称语言中的常用名称重复,就算是解释器允许也不行。无论在任何情况下,都不要命名某个对象为。类似的,避免之类的名称

类型与关键字同名的变量,惯例是在变量名称之后加下划线;相比修改名称的拼写来说,这么做更加可取。例如,如果你将一个 类作为参数传递给一个函数,那么参数名称应该为,而不是(一个例外是静态方法,按照惯例使用作为第一个参数)。

代码之前。正确使用首字母大写和语法,以及保证拼写正确。

代码变更,那么注释可能也需要随之变更。你应该不希望注释与代码表示的意思相反,这很容易导致混淆。

生成,其中包含文件版本的信息。这使得发现文件修改变得容易,尤其是在将模块分发给别人使用时。

代码风格最有争议(也是最常被拒绝使用的)的方面是对行长度的限制。要求行长度不超过个字符,文档字符串不超过个字符。

寸宽屏显示器的时代。是一个非常流行共享代码的网站,所使用的窗口宽度是个字符。

支持者指出很多人依然使用窄屏或字符长度的终端,甚至仅仅是将代码窗口的宽度设置为小于屏幕宽度。

字符宽度的标准或是更宽的标准,你应该按照项目标准的规范编码。当行长度过长时,你应该知道如何处理代码

代码的最佳方式,如下所示:

(really_long_identifier_that_maybe_should_be_shorter

代码清单

方法,而不是在换行符之前使用字符。注意在使用诸如之类的操作符时,尽可能将其置于换行符之前。

函数调用也是可以的。列出了许多可接受的方式完成封装。一般规则是使得同级别行缩进保持一致。

categories=<span style="color: #000000">[

x.y.COMMON_PHRASES,x.y.FONT_PREVIEW_PHRASES,],phrase=<span style="color: #800000">'<span style="color: #800000">The quick brown fox jumped over the lazy dogs.<span style="color: #800000">'<span style="color: #000000">,)

<p style="text-indent: 24.0pt">代码清单<span lang="EN-US">7


<p style="text-indent: 24.0pt">当在函数调用、列表或字典中分行时,在行结尾部分添加逗号。


<h3 style="text-indent: 27.1pt">
<span lang="EN-US">3 小结
<p style="text-indent: 24.0pt">大多数时候,一年后阅读你代码的人就是你自己。记忆并不像一开始时那么好用。在编写代码时没有留心代码的可读性与可维护性自然会使得代码难以阅读和维护。


<p style="text-indent: 24.0pt">通观本书,你学会了如何使用<span lang="EN-US">Python中多种模块、类与结构。当需要决定如何解决问题时,请记住调试代码比写代码更有技术含量。


<p style="text-indent: 24.0pt">因此,以代码尽可能简洁和可读为目标。一年后的你将会感谢自己。当然,你的同事以及下属也会感谢你。


<p lang="EN-US">------本篇结选自本人翻译的书《Python 高级编程》, 清华大学出版社-------------------------------------------------------------------------------------------------

原文链接:https://www.f2er.com/python/69365.html

猜你在找的Python相关文章