pyhton代码规范

>

Python 代码规范

前言

Python 学习之旅,先来看看 Python 的代码规范,让自己先有个意识,而且在往后的学习中慢慢养成习惯

目录

Python代码规范

一、简明概述

1、编码

  • 如无特殊情况, 文件一律使用 UTF-8 编码
  • 如无特殊情况, 文件头部必须加入#-*-coding:utf-8-*-标识

2、代码格式

2.1、缩进

  • 统一使用 4 个空格进行缩进

2.2、行宽

每行代码尽量不超过 80 个字符(在特殊情况下可以略微超过 80 ,但最长不得超过 120)

理由:

  • 这在查看 side-by-side 的 diff 时很有帮助
  • 方便在控制台下查看代码
  • 太长可能是设计有缺陷

2.3、引号

简单说,自然语言使用双引号,机器标示使用单引号,因此 代码里 多数应该使用 单引号

  • 自然语言 使用双引号 "..."
    例如错误信息;很多情况还是 unicode,使用u"你好世界"
  • 机器标识 使用单引号 ‘...‘
    例如 dict 里的 key
  • 正则表达式 使用原生的双引号 r"..."
  • 文档字符串 (docstring) 使用三个双引号 """......"""

2.4、空行

  • 模块级函数和类定义之间空两行;
  • 类成员函数之间空一行;
class A:

    def __init__(self):
        pass

    def hello(self):
        pass

def main():
    pass
  • 可以使用多个空行分隔多组相关的函数
  • 函数中可以使用空行分隔出逻辑相关的代码

2.5、编码

  • 文件使用 UTF-8 编码
  • 文件头部加入#-*-conding:utf-8-*-标识

3、import 语句

  • import 语句应该分行书写
# 正确的写法
import os
import sys

# 不推荐的写法
import sys,os

# 正确的写法
from subprocess import Popen, PIPE
  • import语句应该使用 absolute import
# 正确的写法
from foo.bar import Bar

# 不推荐的写法
from ..bar import Bar
  • import语句应该放在文件头部,置于模块说明及docstring之后,于全局变量之前;
  • import语句应该按照顺序排列,每组之间用一个空行分隔
import os
import sys

import msgpack
import zmq

import foo
  • 导入其他模块的类定义时,可以使用相对导入
from myclass import MyClass
  • 如果发生命名冲突,则可使用命名空间
import bar
import foo.bar

bar.Bar()
foo.bar.Bar()

4、空格

  • 在二元运算符两边各空一格[=,-,+=,==,>,in,is not, and]:
# 正确的写法
i = i + 1
submitted += 1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

# 不推荐的写法
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
  • 函数的参数列表中,,之后要有空格
# 正确的写法
def complex(real, imag):
    pass

# 不推荐的写法
def complex(real,imag):
    pass
  • 函数的参数列表中,默认值等号两边不要添加空格
# 正确的写法
def complex(real, imag=0.0):
    pass

# 不推荐的写法
def complex(real, imag = 0.0):
    pass
  • 左括号之后,右括号之前不要加多余的空格
# 正确的写法
spam(ham[1], {eggs: 2})

# 不推荐的写法
spam( ham[1], { eggs : 2 } )
  • 字典对象的左括号之前不要多余的空格
# 正确的写法
dict[‘key‘] = list[index]

# 不推荐的写法
dict [‘key‘] = list [index]
  • 不要为对齐赋值语句而使用的额外空格
# 正确的写法
x = 1
y = 2
long_variable = 3

# 不推荐的写法
x             = 1
y             = 2
long_variable = 3

5、换行

Python 支持括号内的换行。这时有两种情况。

  1. 第二行缩进到括号的起始处
foo = long_function_name(var_one, var_two,
                         var_three, var_four)
  1. 第二行缩进 4 个空格,适用于起始括号就换行的情形
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

使用反斜杠\换行,二元运算符+ .等应出现在行末;长字符串也可以用此法换行

session.query(MyTable).        filter_by(id=1).        one()

print ‘Hello, ‘      ‘%s %s!‘ %      (‘Harry‘, ‘Potter‘)

禁止复合语句,即一行中包含多个语句:

# 正确的写法
do_first()
do_second()
do_third()

# 不推荐的写法
do_first();do_second();do_third();

if/for/while一定要换行:

# 正确的写法
if foo == ‘blah‘:
    do_blah_thing()

# 不推荐的写法
if foo == ‘blah‘: do_blash_thing()

6、docstring

docstring 的规范中最其本的两点:

  1. 所有的公共模块、函数、类、方法,都应该写 docstring 。私有方法不一定需要,但应该在 def 后提供一个块注释来说明。
  2. docstring 的结束"""应该独占一行,除非此 docstring 只有一行。
"""Return a foobar
Optional plotz says to frobnicate the bizbaz first.
"""

"""Oneline docstring"""

二、注释

1、注释

1.1、块注释

“#”号后空一格,段落件用空行分开(同样需要“#”号)

# 块注释
# 块注释
#
# 块注释
# 块注释

1.2、行注释

至少使用两个空格和语句分开,注意不要使用无意义的注释

# 正确的写法
x = x + 1  # 边框加粗一个像素

# 不推荐的写法(无意义的注释)
x = x + 1 # x加1

1.3、建议

  • 在代码的关键部分(或比较复杂的地方), 能写注释的要尽量写注释
  • 比较重要的注释段, 使用多个等号隔开, 可以更加醒目, 突出重要性
app = create_app(name, options)

# =====================================
# 请勿在此处添加 get post等app路由行为 !!!
# =====================================

if __name__ == ‘__main__‘:
    app.run()

2、文档注释(Docstring)

作为文档的Docstring一般出现在模块头部、函数和类的头部,这样在python中可以通过对象的__doc__对象获取文档.
编辑器和IDE也可以根据Docstring给出自动提示.

  • 文档注释以 """ 开头和结尾, 首行不换行, 如有多行, 末行必需换行, 以下是Google的docstring风格示例
# -*- coding: utf-8 -*-
"""Example docstrings.

This module demonstrates documentation as specified by the `Google Python
Style Guide`_. Docstrings may extend over multiple lines. Sections are created
with a section header and a colon followed by a block of indented text.

Example:
    Examples can be given using either the ``Example`` or ``Examples``
    sections. Sections support any reStructuredText formatting, including
    literal blocks::

        $ python example_google.py

Section breaks are created by resuming unindented text. Section breaks
are also implicitly created anytime a new section starts.
"""
  • 不要在文档注释复制函数定义原型, 而是具体描述其具体内容, 解释具体参数和返回值等
#  不推荐的写法(不要写函数原型等废话)
def function(a, b):
    """function(a, b) -> list"""
    ... ...

#  正确的写法
def function(a, b):
    """计算并返回a到b范围内数据的平均值"""
    ... ...
  • 对函数参数、返回值等的说明采用numpy标准, 如下所示
def func(arg1, arg2):
    """在这里写函数的一句话总结(如: 计算平均值).

    这里是具体描述.

    参数
    ----------
    arg1 : int
        arg1的具体描述
    arg2 : int
        arg2的具体描述

    返回值
    -------
    int
        返回值的具体描述

    参看
    --------
    otherfunc : 其它关联函数等...

    示例
    --------
    示例使用doctest格式, 在`>>>`后的代码可以被文档测试工具作为测试用例自动运行

    >>> a=[1,2,3]
    >>> print [x + 3 for x in a]
    [4, 5, 6]
    """
  • 文档注释不限于中英文, 但不要中英文混用
  • 文档注释不是越长越好, 通常一两句话能把情况说清楚即可
  • 模块、公有类、公有方法, 能写文档注释的, 应该尽量写文档注释

三、命名规范

1、模块

  • 模块尽量使用小写命名,首字母保持小写,尽量不要用下划线(除非多个单词,且数量不多的情况)
# 正确的模块名
import decoder
import html_parser

# 不推荐的模块名
import Decoder

2、类名

  • 类名使用驼峰(CamelCase)命名风格,首字母大写,私有类可用一个下划线开头
class Farm():
    pass

class AnimalFarm(Farm):
    pass

class _PrivateFarm(Farm):
    pass
  • 将相关的类和顶级函数放在同一个模块里. 不像Java, 没必要限制一个类一个模块.

3、函数

  • 函数名一律小写,如有多个单词,用下划线隔开
def run():
    pass

def run_with_env():
    pass
  • 私有函数在函数前加一个下划线_
class Person():

    def _private_func():
        pass

4、变量名

  • 变量名尽量小写, 如有多个单词,用下划线隔开
if __name__ == ‘__main__‘:
    count = 0
    school_name = ‘‘
  • 常量采用全大写,如有多个单词,使用下划线隔开
MAX_CLIENT = 100
MAX_CONNECTION = 1000
CONNECTION_TIMEOUT = 600

5、常量

  • 常量使用以下划线分隔的大写命名
MAX_OVERFLOW = 100

Class FooBar:

    def foo_bar(self, print_):
        print(print_)

原文地址:https://www.cnblogs.com/cmd61/p/11123002.html

时间: 2024-11-03 19:06:01

pyhton代码规范的相关文章

作业三: 代码规范、代码复审、PSP

(1) 是否需要有代码规范         1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西.(反对) 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规

两人合作之代码规范

代码规范 现代软件经过几十年的发展,一个软件由一个人单枪匹马完成,已经很少见了,软件都是在相互合作中完成的.合作的最小单位是两个人,两个工程师在一起,做的最多的事情就是"看代码",每个人都能看"比人的代码",并且发表意见.但是每个人对于什么是"好"的代码规范未必认同,这时我们有必要给出一个基准线-----什么是好的代码规范和设计规范. 1,写干净整洁的代码 1.1 代码格式化,包括多级代码缩进.大括号(比如C系代码),为了提高代码的美观型和易读性

代码规范的重要性

一个规范的代码,通常能起到事半功倍的作用: 一.规范的代码可以促进团队合作 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉.显然的,规范的代码在团队的合作开发中是非常有益而且必要的. 二.规范

最详细的 Swift 代码规范指南

1. 代码格式 1.1 使用四个空格进行缩进. 1.2 每行最多160个字符,这样可以避免一行过长. (Xcode->Preferences->Text Editing->Page guide at column: 设置成160即可) 1.3 确保每个文件结尾都有空白行. 1.4 确保每行都不以空白字符作为结尾 (Xcode->Preferences->Text Editing->Automatically trim trailing whitespace + Incl

项目经理的管理技巧-代码规范

一.系统里面存在的糟糕代码情况有: 1. 代码规范,命名规范和注释 2. 公用代码的抽取和封装 3. 性能低下的代码 4. 表现层.业务层.数据持久层位置存放混乱问题 二.问题 岗位调动,接手一个新的项目组.旧项目一踏糊涂,全部无规范和设计. 组成员各做各的,毫无团队协作能力,更别说团队凝聚力.简直不能更糟糕. 新项目.新成员,新项目重新做了明确规范和框架设计,但组员很多时候不能很好的按照规范进行开发 我有强迫症  三.开始犯的错误,也是最笨的做法 定时核查,自己看到不正确代码同时指出,让开发优

软工学习笔记——代码规范

上大学以来写了这几年的代码,却一直没怎么关注过代码规范相关的问题,直到软工课上讲了之后,才开始有所顾及.上课的时候回头看看自己写过的那些代码,真是丑死了,几个月前自己写的代码现在就已经读不懂了. 看了书上的相关章节,对于我来说,我觉得我的代码主要注意这几点: 1. 少写冗余代码,已经用不到的代码段就应该删去.(我今天刚刚发现我的昆特牌Online项目中竟然还存在有两个没用的类) 2. 多利用空行来将代码小规模地分段. 3. 大段的无用代码不要一直注释着,该删就删.(我的项目里经常会有一大堆没用的

代码规范

1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉. 2.我是个艺术家,手艺人,我有自己的规范和原则 每一个

作业三:代码规范

对于是否需要有代码规范,请考虑下列论点并反驳/支持: 1. 这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 对于以上观点我是反对的 .如果说这些规范都是官僚制度产生的,那么更应该一丝不苟的执行,官僚制度,往大了说是法,应该无条件执行,往小了说是规范,可以帮助我们规范在打代码时自身不好的习惯.也许在编辑代码时,会比随意敲打耽误些许时间,但在检查错误时,规矩的编排格式,可以一目了然的看到自己的错误,为自己节省了更多的时间,会提高开发效率. 2. 我是个艺术家,手

作业三 (一) :是否需要有代码规范

这个作业主要是讨论代码规范的,围绕以下几个问题讨论 1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规