Python编码标准/最佳实践 | Python 实用宝典

问题：Python编码标准/最佳实践

在python中，您通常使用PEP 8-Python代码样式指南作为您的编码标准/准则吗？您还有其他更喜欢的正式标准吗？

In python do you generally use PEP 8 — Style Guide for Python Code as your coding standards/guidelines? Are there any other formalized standards that you prefer?

回答 0

“在python中，您通常使用PEP 8-Python代码样式指南作为您的编码标准/准则吗？您是否还需要其他正式的标准？”

如您所提到的，请遵循PEP 8作为主要文本，并遵循PEP 257作为文档字符串约定

与Python样式指南一起，建议您参考以下内容：

“In python do you generally use PEP 8 — Style Guide for Python Code as your coding standards/guidelines? Are there any other formalized standards that you prefer?”

As mentioned by you follow PEP 8 for the main text, and PEP 257 for docstring conventions

Along with Python Style Guides, I suggest that you refer the following:

回答 1

我遵循Rob Knight 撰写的Python习语和效率指南。我认为它们与PEP 8完全相同，但更多是基于实例的综合。

如果您使用的是wxPython，则可能还需要查看Chris Barker 撰写的wxPython代码的样式指南。

I follow the Python Idioms and Efficiency guidelines, by Rob Knight. I think they are exactly the same as PEP 8, but are more synthetic and based on examples.

If you are using wxPython you might also want to check Style Guide for wxPython code, by Chris Barker, as well.

回答 2

我非常坚持PEP-8。

我有三件事要更改为PEP-8。

避免在括号，方括号或大括号内立即使用多余的空格。

建议： spam(ham[1], {eggs: 2})

无论如何，我这样做： spam( ham[ 1 ], { eggs: 2 } )

为什么？30多年的根深蒂固的习惯使（）与函数名或C语言中的语句关键字不符。从70年代的Fortran IV开始。
在算术运算符周围使用空格：

建议： x = x * 2 - 1

无论如何，我这样做： x= x * 2 - 1

为什么？Gries的《编程科学》建议这是强调赋值与状态被更改的变量之间的联系的一种方式。

对于多重分配或扩充分配，它不太适用，因为我使用了大量空格。
对于函数名称，方法名称和实例变量名称

建议：小写，单词之间用下划线分隔，以提高可读性。

我还是这样做：camelCase

为什么？从80年代的Pascal开始，有20多年根深蒂固的camelCase习惯。

I stick to PEP-8 very closely.

There are three specific things that I can’t be bothered to change to PEP-8.

Avoid extraneous whitespace immediately inside parentheses, brackets or braces.

Suggested: spam(ham[1], {eggs: 2})

I do this anyway: spam( ham[ 1 ], { eggs: 2 } )

Why? 30+ years of ingrained habit is snuggling ()’s up against function names or (in C) statements keywords. Starting with Fortran IV in the 70’s.
Use spaces around arithmetic operators:

Suggested: x = x * 2 - 1

I do this anyway: x= x * 2 - 1

Why? Gries’ The Science of Programming suggested this as a way to emphasize the connection between assignment and the variable who’s state is being changed.

It doesn’t work well for multiple assignment or augmented assignment, for that I use lots of spaces.
For function names, method names and instance variable names

Suggested: lowercase, with words separated by underscores as necessary to improve readability.

I do this anyway: camelCase

Why? 20+ years of ingrained habit of camelCase, starting with Pascal in the 80’s.

回答 3

PEP 8很好，我唯一希望它更难解决的是Tabs-vs-Spaces的神圣战争。

基本上，如果您要使用python启动项目，则需要选择“制表符”或“空格”，然后立即将所有违规者开枪。

PEP 8 is good, the only thing that i wish it came down harder on was the Tabs-vs-Spaces holy war.

Basically if you are starting a project in python, you need to choose Tabs or Spaces and then shoot all offenders on sight.

回答 4

要添加到bhadra的惯用指南列表中：

查阅Anthony Baxter的有关有效Python编程的演示文稿（来自OSON 2005）。

摘录：

# dict's setdefault method turns this:
if key in dictobj:
    dictobj[key].append(val)
else:
    dictobj[key] = [val]
# into this:
dictobj.setdefault(key,[]).append(val)

To add to bhadra’s list of idiomatic guides:

Checkout Anthony Baxter’s presentation on Effective Python Programming (from OSON 2005).

An excerpt:

# dict's setdefault method turns this:
if key in dictobj:
    dictobj[key].append(val)
else:
    dictobj[key] = [val]
# into this:
dictobj.setdefault(key,[]).append(val)

回答 5

我非常严格地遵循它。PEP-8之前唯一的神是现有的代码库。

I follow it extremely rigorously. The only god before PEP-8 is existing code bases.

回答 6

是的，我会尽量紧跟其后。

我没有遵循任何其他编码标准。

Yes, I try to follow it as closely as possible.

I don’t follow any other coding standards.

回答 7

我遵循PEP8，这是很棒的编码风格。

I follow the PEP8, it is a great piece of coding style.