TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Google Python Style Guide

239 点作者 quick_brown_fox超过 2 年前

25 条评论

gorgoiler超过 2 年前
It is a shame that <i>default arguments</i> isn’t a bit longer. Perhaps it’s out of scope to talk about anti-patterns but in my experience default arguments cause a lot of distress to a good code base.<p>Defaults are useful when you are providing a library function for other teams to use. If you’re inside a more private code base and doing work on the implementation of your team’s service then it is wise to avoid default arguments.<p>The problem is they provide a point after which it seems acceptable to add a flood of more default arguments. This is particularly the case for junior developers who lack confidence to refactor instead of patch. Default arguments go hand in hand with conditional logic and cause functions to bloat into do-everything multi-page monsters without any focus and no tractable flow of logic.<p>Forgive the contrived example, but what was once this:<p><pre><code> def greet(name): print(f”Hello {name}”) </code></pre> ends up becoming this, all because no one would bite the bullet and pick this apart into individual functions:<p><pre><code> def greet( name, language=None, io=None, is_ci=False, and_return=False, ): greeting = “Hello” if language: greeting = translate(greeting) message = f”{greeting} {name}” fn = print flush = False if is_ci: fn = log flush = True fn( greeting, flush=flush, io=io if io else stdout, ) if and_return: return greeting </code></pre> The slow rot of more and more defaults makes the function longer and longer. Moreover, each time someone adds a new option it gets harder to justify why they shouldn’t do it when the previous person <i>was</i> allowed.
评论 #34752162 未加载
评论 #34751718 未加载
评论 #34751207 未加载
评论 #34751279 未加载
评论 #34752223 未加载
评论 #34751169 未加载
评论 #34752948 未加载
评论 #34752379 未加载
matsemann超过 2 年前
Pylint is extremely slow, I&#x27;ve preferred flake8 for some time. But now looking into Ruff, handles the whole codebase in less than second (vs minutes). Happy with it so far.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;charliermarsh&#x2F;ruff">https:&#x2F;&#x2F;github.com&#x2F;charliermarsh&#x2F;ruff</a><p>This article also highlights some pain points I have with python. They say avoid big list comprehensions, but there is no nice way of piping data in Python one can switch to instead. Especially with lambdas being so underpowered (so they also say to avoid).<p>They say avoid conditional expressions for all but simple cases, and I agree. Which is what makes me wish everything (like ifs, switches&#x2F;when etc) in Python was an expression (ala elm, kotlin etc). Because right now it&#x27;s hard to assign a variable conditionally without having to re-assign &#x2F; mutate it, which feels unpure.<p>Default arguments being reused between calls is just weird. So I understand the rationale of Google&#x27;s style guide, but it&#x27;s a big flaw in the language imo, lots of weird bugs from novice programmers from that.<p>I disagree on allowing the @property decorator. You think you&#x27;re doing a lookup, but it&#x27;s suddenly a function call doing a db lookup or so. Huge foot gun.<p>I feel the 80 character rule is too low, and often hard to avoid with keyword arguments, to the django orm etc. End up having to litter comments to disable it all over the place, and waste a lot of time when CI breaks.<p>As for formatting, whitespace etc. I&#x27;m over caring about that for languages. I just have some autoformatter set up to fix everything on save, and someone else can argue about the rules.
评论 #34751107 未加载
评论 #34751287 未加载
评论 #34750646 未加载
EdwardDiego超过 2 年前
A Python style preference I&#x27;m rapidly deriving is as soon as there&#x27;s more than two arguments to a function, especially when you&#x27;re mixing in args with defaults, I&#x27;m thinking about enforcing kwarg syntax only at a language level. Just to force the code to be more readable at the call site.<p>E.g.,<p><pre><code> def bla(self, a, b, c=2, d=True): self.bla(&quot;x&quot;, &quot;x&quot;, 3) </code></pre> Ain&#x27;t no way in hell I&#x27;m wanting those arguments to be used positionally by callers. They&#x27;re getting THE KWARG IS MANDATORY STAR.<p><pre><code> def bla(self, *, a, b, c=2, d=True): self.bla(a=&quot;x&quot;, b=&quot;x&quot;, c=3) </code></pre> It adds more vertical to your code when you have meaningful argument names, but it makes it a lot clearer what is what, and the language enforces what just used to be a good style.<p>It&#x27;s especially important when Python&#x27;s mocking comes into play.<p>In languages like Java, you can determine what is what based on types... (with static imports for both)<p><pre><code> X x = new X(mock(Y.class)); </code></pre> Makes it far clearer what X is working with than<p><pre><code> x: X = X(MagicMock())</code></pre>
评论 #34751083 未加载
评论 #34751127 未加载
评论 #34750990 未加载
drahazar超过 2 年前
<p><pre><code> 2.14 True&#x2F;False Evaluations Use the “implicit” false if at all possible. </code></pre> This one is my personal bug-bear. I find this:<p><pre><code> if not users: ... </code></pre> significantly worse than:<p><pre><code> if users == []: ... </code></pre> The second is totally explicit, reminds the reader that users is (expected to be) a list and makes it totally clear that we can only enter the conditional block if users is an empty list.<p>The first option:<p>a) obfuscates the type of users on first reading<p>b) evaluates to True if users is None (or LOADS of other things?!) which can lead to hard-to-find bugs.<p>Granted, type-checking can help here but purely from a readability perspective the second option seems way more friendly and for almost no downside. The same holds true for all of the &quot;False-y&quot; objects:<p><pre><code> if users == {}: if users == 0: if users is None: if users == (): if users is False:</code></pre> Why is the implicit:<p><pre><code> if not users:</code></pre> an improvement in any of these cases?<p><pre><code> If you need to distinguish False from None then chain the expressions, such as if not x and x is not None:. </code></pre> !!!<p>Why not just:<p><pre><code> if x is False: ?</code></pre>
评论 #34751039 未加载
评论 #34751114 未加载
评论 #34751021 未加载
评论 #34751035 未加载
评论 #34754142 未加载
评论 #34751110 未加载
评论 #34760549 未加载
评论 #34752076 未加载
评论 #34751020 未加载
评论 #34752187 未加载
评论 #34751281 未加载
cjfd超过 2 年前
I hate style guides.<p>Probably the worst thing about this one is the pydoc. An not just pydoc. Pydoc, javadoc, doxygen. It is all useless garbage that litters the code with useless comments explaining that the get_height method &quot;gets the height&quot; while at the same time nobody is actually explaining anything remotely useful in comments.
评论 #34750957 未加载
评论 #34750988 未加载
评论 #34751858 未加载
评论 #34752531 未加载
评论 #34753642 未加载
评论 #34751752 未加载
评论 #34751241 未加载
评论 #34750892 未加载
评论 #34751901 未加载
评论 #34750933 未加载
usrme超过 2 年前
To those that wish to automate a subset of these conventions, there is a tool called Sourcery[1] that I, personally, am a huge fan of! Not only does it have a large set of default rules[2], but it can also allow you to write your own rules that may be specific to your team or organization, and as mentioned it can enable you to follow Google&#x27;s Python style guide as well[3].<p>There are some refactorings that Sourcery suggest that I don&#x27;t agree with myself, namely the usage of &#x27;contextlib.suppress&#x27;[4] as I don&#x27;t like to introduce an additional &#x27;import&#x27; statement just to do something so trivial. I wish Sourcery would add the relevance of having possibly too many &#x27;import&#x27; statements as a heuristic.<p>---<p>[1]: <a href="https:&#x2F;&#x2F;sourcery.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sourcery.ai&#x2F;</a><p>[2]: <a href="https:&#x2F;&#x2F;docs.sourcery.ai&#x2F;Reference&#x2F;Default-Rules&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.sourcery.ai&#x2F;Reference&#x2F;Default-Rules&#x2F;</a> (expand the sub-pages)<p>[3]: <a href="https:&#x2F;&#x2F;docs.sourcery.ai&#x2F;Reference&#x2F;Optional-Rules&#x2F;gpsg&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.sourcery.ai&#x2F;Reference&#x2F;Optional-Rules&#x2F;gpsg&#x2F;</a><p>[4]: <a href="https:&#x2F;&#x2F;docs.sourcery.ai&#x2F;Reference&#x2F;Default-Rules&#x2F;refactorings&#x2F;use-contextlib-suppress&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.sourcery.ai&#x2F;Reference&#x2F;Default-Rules&#x2F;refactoring...</a>
dang超过 2 年前
Related:<p><i>Python Style Guide from Google</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11839332" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11839332</a> - June 2016 (27 comments)<p><i>Google&#x27;s Python style guide</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3861617" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3861617</a> - April 2012 (86 comments)<p><i>Google Python Style Guide</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1311126" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1311126</a> - May 2010 (23 comments)
woadwarrior01超过 2 年前
One thing I never understood from it is the recommendation to avoid staticmethods, classmethods[1]. I was befuddled by it at first, looked it up on moma, and even asked around, but never got a convincing answer during my time there. IIRC, their C++ style guide had even stronger opinions, diverging from the norm.<p>[1]: <a href="https:&#x2F;&#x2F;google.github.io&#x2F;styleguide&#x2F;pyguide.html#217-function-and-method-decorators" rel="nofollow">https:&#x2F;&#x2F;google.github.io&#x2F;styleguide&#x2F;pyguide.html#217-functio...</a>
评论 #34751014 未加载
评论 #34751041 未加载
评论 #34752172 未加载
saghul超过 2 年前
I seem to remember they used to indent Python code with 2 spaces. Glad to see it&#x27;s 4 now.
评论 #34750962 未加载
评论 #34754746 未加载
评论 #34750987 未加载
评论 #34750658 未加载
评论 #34752351 未加载
game_the0ry超过 2 年前
Content aside, as a front end dev, I am liking the clean design of that site:<p>* no goofy animations (no slide down when the table of contents expands, just BOOM open)<p>* no distracting images &#x2F; icons<p>* no dark mode toggle (blasphemous nowadays, I know...)<p>* black and white<p>* logical font sizing for section &#x2F; sub section numbers<p>Just clean and simple. My compliments to the designer.
评论 #34752461 未加载
vitorsr超过 2 年前
See also how yapf defines the Google formatting style:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;yapf&#x2F;blob&#x2F;v0.32.0&#x2F;yapf&#x2F;yapflib&#x2F;style.py#L484-L500">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;yapf&#x2F;blob&#x2F;v0.32.0&#x2F;yapf&#x2F;yapflib&#x2F;sty...</a>
wheelerof4te超过 2 年前
I would always prefer keyword argument calling in a professional environment.<p>The exception to this rule could be functions that have only one argument.
Narann超过 2 年前
About the relative imports: <a href="https:&#x2F;&#x2F;google.github.io&#x2F;styleguide&#x2F;pyguide.html#233-decision" rel="nofollow">https:&#x2F;&#x2F;google.github.io&#x2F;styleguide&#x2F;pyguide.html#233-decisio...</a><p>The guide states this is unclear:<p><pre><code> import jodie </code></pre> I agree, but why not using:<p><pre><code> import .jodie</code></pre>
mark_l_watson超过 2 年前
I was happy to see “Nested local functions or classes are fine”<p>Being a mostly Lisp developer, I like to nest local functions in order to close over locally defined variables. Glad that is considered OK in Python.
Pandabob超过 2 年前
I’m personally defaulting to pylance, flake8, black, mypy (strict), autoflake and isort to keep my Python code sensible. That said, it usually takes me like 15 minutes to set this all up in VSCode.
评论 #34752607 未加载
评论 #34754034 未加载
gonzo41超过 2 年前
Golang has the right idea. There&#x27;s an inbuilt language style and what you think matters doesn&#x27;t because there&#x27;s already a formatting tool and we&#x27;ll all bend to it&#x27;s will.
评论 #34750628 未加载
评论 #34750702 未加载
评论 #34751095 未加载
jwmoz超过 2 年前
80 chars line width is too small imho. This isn’t the 90s anymore.
评论 #34754970 未加载
wdroz超过 2 年前
&gt; Use the “implicit” false if at all possible.<p>I understand that it make the code less verbose, but I don&#x27;t agree that is &quot;less error prone&quot; as stated.<p>&gt; May look strange to C&#x2F;C++ developers.<p>Yes..
stellalo超过 2 年前
Nitpick<p>“2.5 Mutable Global State<p>Avoid mutable global state.<p>[…]<p>2.5.2 Pros<p>Occasionally useful.”<p>So, are these pros of mutable global state or of avoiding it? Elsewhere pros and cons appear to refer to the description of the guideline, not the title (see 2.2 Imports).
评论 #34750650 未加载
评论 #34751751 未加载
AlbertCory超过 2 年前
It&#x27;s worth noting that Guido himself had an, um, &quot;interesting&quot; time getting Python Readability at Google.
moomoo11超过 2 年前
This is cool but my biggest issue with python is how difficult it is to just use without blowing up my workstation.<p>Honestly even with a version manager it can become a nightmare and it’s the primary reason I’ve stayed away from it. Also because I’m really a mathematician or something who needs to use any of the extensive python libraries to do some cool AI stuff.<p>Here’s to hoping I never have to deal with actually maintaining or working on a python codebase. Cheers!
评论 #34751190 未加载
评论 #34751896 未加载
评论 #34753424 未加载
shmde超过 2 年前
Are there any similar guide for React&#x2F;TS&#x2F;JS. Or frontend in general?
jstx1超过 2 年前
Prefixing with underscores to pretend that a variable is private still seems like the most pointless and ugly thing ever.
评论 #34750964 未加载
评论 #34750919 未加载
评论 #34751303 未加载
评论 #34756867 未加载
评论 #34754421 未加载
cramjabsyn超过 2 年前
Google again with the not invented here syndrome
iamsanteri超过 2 年前
WHAT, always use four spaces instead of TAB?? Oh my god.
评论 #34751081 未加载
评论 #34751000 未加载
评论 #34754820 未加载