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.
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.
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.
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.
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.
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.
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).
(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.
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.
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.
29 comments
[ 4.6 ms ] story [ 61.6 ms ] threadStill no exceptions, though.
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.
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
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.
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.
What is the advantage that spaces have over tabs?
Imagine this diff in the middle of a file (in Javascript)
vsLines 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.