Python Style Guide from Google | Hacker News Reader

Python Style Guide from Google

google.github.io

47 pointsmmphosis27 comments

One thing I find odd is to prohibit classes / functions from being imported, instead forcing to always write their module names for the fear of namespace collisions. Is this common for Python in organisations? Did I get something wrong? Seems to a little bit too much on the Java side of this tradeoff.

I prefer importing whole modules too. One of the benefit is much easier code reviews:

Imagine this diff in the middle of a file (in Javascript)

  if (includes(users, userId)) {
    open(load(userId))
  }

  if (_.includes(users, userId)) {
    Modal.open(UserApi.load(userId))
  }

Code with many from... imports becomes very unreadable very fast.

Google's C++ style guide is much more interesting: https://google.github.io/styleguide/cppguide.html

In that it destroys a greater proportion of the language's expressive power? :-p

It has improved considerably since the adoption of (much of) C++11.

Still no exceptions, though.

The advantage of exceptions is not so much their "expressive power", but the fact that they provide an approximation to error handling even when nobody remembers to express it.

If my team had some process (via code review, static analysis, or anything else) that could ensure error returns were actually checked and handled, then the case for exceptions would be much diminished.

I mostly agree. We do have that in the form of static analysis, Status and StatusOr return types, and MUST_USE_RESULT (which is also visible in external codebases like V8). There's still a fair amount of boilerplate, but on the other hand control flow transfers are explicit, so it's a trade-off.

> some process

Or something like Rust's `Result<T,E>` type? You can't possibly forget to `match` it, and if you `unwrap` it, it will be plain obvious, both to humans and to linters.

http://doc.rust-lang.org/std/result/index.html

The only rule that would bother me is the max line width of 80 characters. Why still stick to this rule with today's screens? I usually set this to 200.

Just because you have a screen that can display an enourmously long line of text, it doesn't mean that text is going to be readable. Or that you want to use the whole width of your screen for displaying unreadable text.

Lines longer than 100 chars are very rare in readable code. And it is easy to break lines down to 80 or even 72. If you do that, then it becomes easy to place two windows of good sized text side-by-side.

You can view/edit 3 files side by side instead of only one.

Google internally does not always follow this guide. Different project can come up with its own style.

They /can/ but I've found that almost every team I've interacted with sticks with the style recommended by g4 lint.

Note that this is the public style guide (intended for contributions to Google open-source projects). The internal style guide has some differences, mainly to more-closely match the styles of internal C++ and Java (things like naming and indenting).

In my experience, any Python code in the core codebase follows the (internal) style guide. Big mostly-standalone projects like YouTube have their own style.

4 spaces? seriously? Why would anyone type out 4 spaces instead of one tab?

You configure your editor to expand a tab into four spaces.

Personally, i use tabs of size four with expandtabs setting. That way i don't have to press four spaces and my files look the same across all editors and platforms.

I thought everybody does that..who the hell would type space 4 times?

A good reason for sticking to monospace characters is that they're always displayed the same, regardless of your personal editor and editor configuration choices.

Also, you don't need to type 4 (or however many) spaces directly. Most programming editors can be configured to insert spaces when you press tab, or to replace existing tabs in a file to spaces.

Virtually everyone does type one tab and uses a text editor that expands the tab to four spaces in the file.

Yep. I've never really understood why editors tend to replace the tab with spaces, though. It seems to work pretty much the same when indenting, but involves more backspacing and introduces more potential for error (eg. deleting 3 spaces instead of 4) when deleting.

What is the advantage that spaces have over tabs?

They ensure uniformity regardless of how your editor is set up. E.g. the default vim setting is to display tabs as eight spaces, which means that viewing a file with tabs (or, even worse, a mixture a tabs or spaces) will look differently if viewed on a newly-set server than in my regular IDE (which is set to display a tab as four spaces).

Atom at least treats soft tabs as tabs for the most part, when you backspace into a soft tab it will delete all 4 spaces at once.

Richard Hendriks? Is that you?

(The last episode of Silicon Valley referenced the tabs vs. spaces debate with exaggerated examples of hitting the space bar four times to indent. This probably isn't a serious question.)

There's that balance between readability and being able to operate in highly nested structures and for loops while all kinds of matrix multiplication in AI/ML for example. Minimizing wrapping is important here and you do with 4 spaces, not 8.

Reply on news.ycombinator.com