一、代码风格 1、假定你的代码需要维护2、保持一致性3、考虑对象在程序中存在的方式,尤其是那些带有数据的对象4、不要做重复工作5、让注释讲故事6、奥卡姆剃刀原则1、简洁的规则2、文档字符串3、空行4、

刚开始学的时候就要注意编码规范了,所以整理了一下,以便养成一个编码好习惯。不然以后真的不好改。

代码被读的次数远大于被写的次数。

作为一名程序员(使用任何语言),你能做出最重要的事情之一就是写出易于阅读的代码。

原则

在开始讨论Python社区所采用的具体标准或是由其他人推荐的建议之前,考虑一些总体原则非常重要。

请记住,可读性标准的目标是提升可读性。这些规则存在的目的就是为了帮助人读写代码。

1、假定你的代码需要维护

你很容易相信在某时自己所完成的工作在未来不需要添加内容或对其进行维护。在编写代码时,你很难预料到未来的需求,并且会低估自己引入Bug的倾向。然而,所编写的代码很少不需要修改一直存在的。

如果你假设自己的编写的代码会‘一劳永逸’,之后无需再阅读、调试或修补,那么就会非常容易陷入忽视其他可读性原则的境地。这仅仅是因为你相信‘这次你编写的代码不会需要修改,所以不用花费时间编写可读性高的代码’。

因此,对自己所写代码不需维护的直觉不相信才是上策。稳赚不赔的办法是赌自己将会再次看到自己编写的代码。即使你不维护,别人也会维护。

2、保持一致性

一致性的两个方面分别为:内部一致性和外部一致性。

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

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

3、考虑对象在程序中存在的方式,尤其是那些带有数据的对象

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

而对于写软件程序来说,存在论指的是关注不同的“事物”在应用程序中的存在方式。如何在数据库中表示概念?或是用类结构来表示?

这类问题最终影响你编写或组织代码的方式。是否使用继承或组合来组织两个类之间的关系?使用数据库的哪个表来完成这项功能或是这个列属于那个表?

这些建议最终归结为“在编写代码之前先思考‘’,尤其是思考程序希望实现的目标,以及应用程序之间如何交互,应用程序是一个对象与数据交互的世界。那么,它们之间的协作需要遵循的规则是什么?

4、不要做重复工作

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

同样的原则用于函数。在应用程序中你是否拥有大量的重复代码?如果这些重复代码行数较多,可以先将其抽象到一个函数中去,如果出现修改的必要,则更容易管理。

另一方面,对于这个原则不要过犹不及。并不是所有的值都需要在某块中定义常量(这样有损可读性和维护性)。请明智判断,不断问自己这样的问题:“如果需要变更该代码,在所有位置进行变更所需要的成本是多少?”。

5、让注释讲故事

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

采用的注释风格可以是在每某一些行代码之前就添加一段注释,用于解释代码的功能。如果代码时一个故事,那么注释就是故事的解释与旁白。

如果叙事型注释做的好,读者就可以通过阅读注释了解故事,从而解析代码(例如,当尝试解决问题或维护代码时),然后就可以从零开始快速了解所需维护的代码,这样就可以专注于代码本身所表示的意义。

叙事型注释还可以帮助解释代码的意图。它可以回答这样的问题:“这段代码的编写者需要完成的目的是什么?”,偶尔,还可以帮助回答问题:“为什么以这种方式完成工作”?这些问题是你阅读代码时很自然就会问的问题为这些问题提供答案有助于了解这些内容。

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

6、奥卡姆剃刀原则

通俗来讲,编写可读性代码最重要的原则就是奥卡姆剃刀原则:最简单的解决方案通常是最好的。在他的“Python之禅”的博文页面中(http://www.python.org/dev/peps/pep-0020/),集合了一些编程格言(例如在Python的控制台中输入"import this"就可以看到这篇博文),Tim peters 也包括类似下面格言:“如果你无法想别人描述你的方案,那肯定不是一个好方案”。

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

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

标准

Python社区大部分遵守所谓的 PEP 8(http://www.python.org/dev/peps/pep-0008)指导原则,PEP 8由Guido van Rossum(Python之父)编写并被大多数主流Python项目所采用,其中包括Python的标准库。

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

1、简洁的规则

  • PEP 8的大多数指导原则都很简单明了,部分重点如下
  • 使用4个空格缩进,而不是制表符(Tab键)
  • 变量应该使用下划线连接,而不是驼峰式命名规则(使用my_var 而不是myVal)。类名称以字母开头就是驼峰式命名风格(例如:MyClass)
  • 如果一个变量的用处是:“仅内部使用”,那么在变量名称之前加上下划线。
  • 在运算符前后加上单空格(例如,x + y,不是x+y),也包括赋值运算符(z = 3,不是z=3)。只有在关键字参数的情况下该规则不适用,在这种情况下,空格可以省略。
  • 在列表和字典省略不必要的空白(例如:[1,2,3,4]而不是[ 1,2,3,4 ])。

2、文档字符串

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

PEP 8规定文档字符串的是必须的

‘’‘Do  X , Y, and Z, then return the result. ’‘’

如果文档字符串是一行,那么需要在类或函数体之前加空行。如果文档是多行,则将结束的双引号单独的放一行。

3、空行

空行用于逻辑分块。

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

class A(object):
    pass


class B(object):
    pass 

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

class A(object):
    def foo(self):
        pass

    def bar(self):
        pass

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

4、导入

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

在Python3中,使用特殊语法来标记相对导入——以(.)开头——‘正常’的导入方式只会尝试相对路径。Python3的语法在Python2.6以后的版本可以使用,另外,可以使用from_future_import absolute_import关闭隐式的相对导入。

 如果可能,尽量使用绝对路径导入。如果必须使用相对路径,请使用显示的导入风格。如果你是Python2.6、Python2.7编码,请考虑选择Python3的显示风格。

当导入模块时,每个模块应该单独占一行。

import os
import sys

然而如果从一个模块导入多个名称,可以将这些名称分组到一行中。

from datetime import data, datetime, timedelta

此外,虽然PEP 8并没有强制要求,但可以考虑以包的形式将导入分组。对于每一组,按照字母表顺序排序。

另外,在导入时,请不要忘了使用as关键字给导入的内容起别名。

from foo.bar import really_long_name as name

这使得你可以简化被频繁使用的长名或不规范命名的名称。

5、变量

如前所述,变量名称使用下划线连接,而不要使用驼峰式代码风格,此外,起一个具有描述性的名称同样重要。

通常情况下,使用非常短的变量名称并不合适,虽然某些情况下这样做也能接受。如:(for k , v in a)。

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

如果必须要命名一个与Python关键字同名的的变量,惯例是在变量名之后加下划线;相比修改名称的编写来说,这样更加可行。例如你想使用class,应该是class_。

6、注释

注释的编写应该使用英语的完整语句,注释块应该放在相关代码之前。首字母大写,拼写正确。

同时要保证注释更新。如果代码变更,注释也要变。

模块可能包含一个注释头,通常有版本控制系统生成,其中包括文件版本的信息。这使得查看文件是否被修改变得 容易,尤其是将模块分发给别人使用时。

7、行长度

PEP8 要求行长度不超过79个字符,文档字符串不超过72个字符。

当行过长时,使用圆括号封装是最佳方式,也可以使用‘\’字符。

大多时候,一年以后阅读你代码的是你自己,你的记忆力并不像一开始写代码这么好,良好的编码风格,会增加你代码的可读性。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏C/C++基础

C++为什么要引入异常处理机制

在程序设计中,错误时不可避免的。及时有效的发现错误,并作出适当的处理,无论是在软件的开发阶段还是在维护阶段都是至关重要的。错误修复技术是提高代码健壮性的最有效的...

891
来自专栏Python入门

你还在为Python中文乱码而感到烦恼?今天老司机给你讲讲!

有没有遇到过这样的问题,读取文件被提示“UnicodeDecodeError”、爬取网页得到一堆乱码,其实这些都是编码惹的祸,如果不能真正理解编码的问题所在,就...

1663
来自专栏Java技术栈

Java 编程中关于异常处理的 10 个最佳实践

异常处理是Java 开发中的一个重要部分。它是关乎每个应用的一个非功能性需求,是为了处理任何错误状况,比如资源不可访问,非法输入,空输入等等。Java提供了...

1664
来自专栏ThoughtWorks

TW洞见〡getter和setter的那些事

文章作者来自ThoughtWorks:佟达 相信每一个以Java或者C++作为编程入门语言的程序员,一定会记得一条金科玉律:字段(Filed)要声明成priv...

3116
来自专栏ImportSource

必懂的NoSQL理论-Map-Reduce(中)

本文主要内容:分区和归并 上一文:必懂的NoSQL理论-Map-Reduce(上) Partitioning and Combining 分区和归并 在最简单...

3356
来自专栏java相关

设计模式之—模版方法模式

这种模式在我们开发中经常会用到,一个简单的例子,我们在抽象类中定义若干个基本的操作,在具体的实现类中定义模版方法对基本方法实现聚合。这种实现方式就可以称为模版方...

1284
来自专栏大内老A

WCF技术剖析之二十二: 深入剖析WCF底层异常处理框架实现原理[上篇]

对于上一篇文章 (WCF基本异常处理模式:[上篇]、[中篇]、[下篇]),主要是站在最终开发者的角度对WCF关于异常处理编程模式进行了介绍,接下来,我们需要将我...

2039
来自专栏BestSDK

18个Java小技巧,从运行、控制到框架

1. JVM相关 JVM作为java运行的基础,很难相信对于JVM一点都不了解的人可以把java语言吃得很透。我在面试有超过3年Java经验的开发者的时候, J...

3536
来自专栏王清培的专栏

Redis 数据结构与内存管理策略(上)

Redis 数据结构与内存管理策略(上) 标签: Redis Redis数据结构 Redis内存管理策略 Redis数据类型 Redis类型映射 作者:王清培(...

3317
来自专栏C/C++基础

C++异常处理的开销

C++异常是C++有别于C的一大特性 ,异常处理机制给开发人员处理程序中可能出现的意外错误带来了极大的方便,但为了实现异常,编译器会引入额外的数据结构与处理机制...

892

扫码关注云+社区

领取腾讯云代金券