
If I could amend PEP 8 - voltagex_
https://www.kennethreitz.org/essays/if-i-could-amend-pep-8
======
Daishiman
With regards to string quotes, I've always used this idiom, which I find
fantastic:

For strings that are meant for human consumption, use double quotes, otherwise
use single quotes.

This is super practical when looking strings meant for translation, end-user
formatting, and such.

~~~
thebspatrol
I love this. I've always followed this guideline without thinking about how to
communicate it.

I'm fairly sure that single quotes are much more common in the UK in
literature, though, so this only feels like it makes sense to NA and AU
speakers.

~~~
OJFord
> _I 'm fairly sure that single quotes are much more common in the UK in
> literature, though_

It's just that the primary/secondary role is reversed. (This is also reflected
in which one you have to hold Shift for on a computer keyboard.)

------
zepolen
I don't agree with allowing characters to go over 80 - there is rarely a time
the code can't be broken down to fit.

80 characters helps a lot since you can count on all code to fit within a
certain area - so you can run three side/side text buffers in your text
editor, instead of two with lots of useless white space because a few lines
might be too long.

Doing a simple overview of the requests library, most of the lines over 80
characters are just laziness such as:

[https://github.com/kennethreitz/requests/blob/master/tests/t...](https://github.com/kennethreitz/requests/blob/master/tests/test_utils.py#L153)

And a few of the actual potential cases for going over 80 characters can still
be broken down without losing any readability:

[https://github.com/kennethreitz/requests/blob/master/request...](https://github.com/kennethreitz/requests/blob/master/requests/auth.py#L105)

    
    
              r.headers['Proxy-Authorization'] = _basic_auth_str(self.username,
                                                                 self.password)

~~~
ergo14
I have lots of classes and method names that are descriptive but also make 80
chars harder to read. In past I've had to sacrifice readibility to follow
strict 80 char limit rule it is a bad idea to enforce it. 99% of time you are
not doing merges that require you to have 3 side by side buffers. It makes no
sense to point this as the main reason to maintain the limit in my opinion.
100 char limit is way more sane, 95% of time 79 is enough for me but for the
remaining 5% to enforce it means to actually make it less readable or make
more cryptic variable names which is even worse imo..

~~~
zepolen
I like descriptive names too, EvenToThePointOfAbsurdity, but if the 80 char
limit is starting to be imposing, it's usually an indication that code should
be refactored as it's being indented too much, or one thing is trying to do
too many things.

3 side/side buffers is arbitrary, (it would be 2 on a small laptop display) -
and maybe that's why I like 80 characters, it lets me develop on any screen
without needing more real estate because the files are long.

I mean Angular has iirc 120 characters, and if you take a look at an average
source file eg:

[https://github.com/angular/angular/blob/master/modules/%40an...](https://github.com/angular/angular/blob/master/modules/%40angular/http/src/headers.ts)

You'll see a ton of white space after 80 characters that is 'wasted' \- this
also eats up into horizontal real estate of another buffer which in the end
means you actually have less information on the screen with >80 characters
rather than more.

In all cases - the code in that file could easily be broken into multiple
lines and not lose _any_ readability.

~~~
OJFord
> * 3 side/side buffers is arbitrary, (it would be 2 on a small laptop
> display) *

It's about 1/3 of my 13" 2013 Macbook Air - the other 2/3 is usually a
browser.

It's also not even about how much horizontal space there is for any reason -
it just scans better if you keep it narrower.

------
pmiller2
I think this concern over an absolute limit on line length is overblown. Where
I work now, we don't use a hard limit on line length. The rule is "keep it
readable." That usually means lines less than 100 characters. I try to keep it
below 80 myself, but I wouldn't complain about a 120 character line.

I did a search through our codebase for line lengths over 80 or 100 characters
and found remarkably few. Most were comment lines.

------
Sivart13
In situations where the language allows either quote, I think any ounce of
time spent by anyone debating to use one or the other is pure waste, including
this comment.

Just do whatever you feel like. If your editor, linter, or review process
makes you change it, those things are broken.

~~~
akvadrako
Inconsistency is not the end of the world but it hurts readability, slightly
complicates find/replace and I find it just ugly.

The fact that the codes works is most important, but being nice to work on
comes a close second.

~~~
antris
Code that doesn't work but is readable can at least be fixed.

------
guitarbill
Agreed, "aligned with opening delimiter" is brain dead, you just waste time
re-justify everything if you refactor. It's just more effort in the long run,
and for what? It isn't prettier, more readable, or more convenient.

As for strings, meh. But consistency is nice. Line length exceeding an
arbitrary standard, fine. Rules can be broken if there's a good reason.

~~~
merlincorey
> Agreed, "aligned with opening delimiter" is brain dead,

As a smug lisp weenie that has been working in python for many years, I
completely disagree with this.

> you just waste time re-justify everything if you refactor.

A single `indent-region` in emacs and you are rejustified, no trouble.

> It's just more effort in the long run, and for what?

It's more effort as opposed to what, exactly?

> It isn't prettier, more readable, or more convenient.

It is, to me, prettier, but I think, objectively, it is more readable than
alternatives, especially if there is any kind of nesting involved.

I concede that if there is nesting involved, you might be bumping into other
python style issues, and generally might want to add some intermediate
variables, etc; however, I do believe that in at least some cases this is
entirely inconvenient, and so the lisp way of aligning parameters with their
delimiter is the way to go in those cases. Anything else would be quite a bit
less readable.

~~~
guitarbill
> > you just waste time re-justify everything if you refactor.

> A single `indent-region` in emacs and you are rejustified, no trouble.

Because when you refactor the function/class name, it's never just one region.
So now you have to go back and indent all occurrences, maybe even over
multiple files. Brilliant!

~~~
dkbrk
> Because when you refactor the function/class name, it's never just one
> region

... the region is whatever you say it is:

    
    
      (mark-whole-buffer)
      (indent-region)
    

Or, most likely, something like: C-x h TAB

I don't think that's particularly onerous.

It's only a few lines of elisp to visit all the files in a tree and
automatically format them. That said, it would probably be more sensible to
modify whatever refactoring tool to be indentation aware, if it isn't already.
Again, that's easy to do with elisp.

------
Smaug123
The one I don't like is the asymmetrical block-quotes in docstrings:

"""This line doesn't start at the start.

But this one does, and the following one ends at the start.

"""

~~~
EvilTerran
Yeah, agreed. My multiline strings (docstring or otherwise) almost always look
like

    
    
        """\
        This line starts at the start.
        And so do the following ones.
        """

------
Acalyptol
For me having to read even the ugliest code is better than having to
horizontally scroll. Anyone who thinks there is a single one line of code for
which it's legit to go beyond 80 characters is either masochist or using a
view with more than 80 characters in available width.

------
pmontra
I use a proportional font so it's hard to know where the 80th character is. I
just try to be reasonable. Btw, proportional fonts look much better. It took a
week to adapt.

What I'll amend is the rule about not having spaces around = in argument
lists. It looks horrible and it induces some people at omitting spaces in
assignments. I've never seen so many var=value in source code as in Python,
since the time of PHP.

------
odiroot
Personally, I would have hard time with single quotes point.

Double quotes are just so much easier to catch visually.

~~~
akvadrako
Not with color syntax highlighting. I find double quotes unnecessary noise.

------
cdelsolar
How do they suggest you indent function arguments? The Javascript way? Because
I don't like that one at all.

~~~
jsmeaton
This is my preference for function calls and defs that get too long, usually
due to indentation or whatever.

    
    
      function_call(
          arg1, arg2, arg3
      )
    
      def function_call(
          arg1, arg2, arg3
      ):
          pass

~~~
cdelsolar
noooo

):

------
Spiritus
>Line-length can exceed 79 characters, to 100, when convenient.

My issue with this is that, in reality, everything will now be 100 chars.

~~~
rootlocus
There are actually few places where lines need to be this long. If you keep
indentation low (by refactoring) most of the lines don't get to 80.

