4 ms·

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 cou

by zepolen 10y ago

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/test_utils.py#L153 https://github.com/kennethreitz/requests/blob/master/tests/t... 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/requests/auth.py#L105 https://github.com/kennethreitz/requests/blob/master/request... r.headers['Proxy-Authorization'] = _basic_auth_str(self.username, self.password)

ergo14 10y ago
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 10y ago
  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/%40angular/http/src/headers.ts https://github.com/angular/angular/blob/master/modules/%40an... 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 10y ago
    > * 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.
middleclick 10y ago
I was in the camp of "I disagree with 79 character rule" when I started. However, as someone who has written lots of Python for work, I realized that it does make the code look more readable and while I used to do it initially out of compliance with the existing code, I now do it it because I like it. Does anyone else feel this way? Or I like it because I had to do it and therefore had to like it in the process.
- adisbladis 10y ago
  I was the same and of the opinion that this was mostly a relic of the past. Then I was assigned a project where this was enforced in the test suite and had to religiously follow pep8. It took a while to get used to but after a while the benefits (like fitting into everyone's editor configuration, cleaner list comprehensions etc) became apparent. Now I'm the one to put flake8 as a part of the test suite in any new python project :)
raverbashing 10y ago
> there is rarely a time the code can't be broken down to fit. Yes, it can. It also might end up being: a) less readable, b) uglier Resources are limited so I'd rather devote my efforts to fixing major styling problems rather than a line that goes over 3 characters Having a hard limit is overblown nitpickness (and even the 1st line of Pep8 warns you against those) Not to mention how to do line continuation involves different conflicting styles
- zepolen 10y ago
  Find an example in your code base where you had to go over 80 characters. find . -name '*.py' | xargs grep -n '^.\{80\}' and post it here.
  - raverbashing 10y ago
    You "don't" need to go over 80 chars. But it's stupid to break a line like this in two stuff.do_something_funny(abc, def, ghi) when the limit is reached at the 3rd parameter (or worse, at the parenthesis)
  - stinos 10y ago
    By that reasoning you could almost say 'find an example where you had to go over [insert arbitrary number between 50 and 100 or so]'. If the number if low enough or my screen is wide enough I could fit 4 text editor panes next to each other :] Any code could probably be broken up to match that as well. Don't get me wrong, I personally think 80 is a fine number and it's what I use myself. But making things like this hard rules for what basically are arbitrary reasons (e.g. depending on screen resolution) doesn't seem right in my book. I'm seriously not even considering doing something about a line if it's 81 characters.
  - fnord123 10y ago
    Not python, but in Java, identifiers can get quite long. e.g.: "localizableRUNTIME_MODELER_PORTNAME_SERVICENAME_NAMESPACE_MISMATCH" is the longest at 66 characters. As for python, some fancy list comprehensions get rather long rather quickly. Especially if itertools are involved as you izip, etc. Or using useful variable names (i.e. not 'fcnt', 'tcnt') while destructuring as in this example from pyspark/mllib: (failure_count, test_count) = doctest.testmod(globs=globs, optionflags=doctest.ELLIPSIS) I adapted your grep to: find . -name '*.py' | xargs grep -n '^ *.\{80\}' So leading indentation doesn't mess with the results.
jammycakes 10y ago
While 80 characters may be a bit restrictive, there is a need for a hard limit of something. I've found that in the absence of a hard limit, you all too quickly end up with a codebase riddled with 250+ line monsters forcing you to scroll right and left all over the place just to get the faintest smidgen of an idea of what's going on. It's a maintenance nightmare. Meanwhile, GitHub won't show lines longer than 132 characters (on Windows) or 123 characters (on the Mac) without scrolling, no matter how wide your screen. I personally find 100 seems to strike the right balance.
rtpg 10y ago
very dependent on the language imo C tends to be terse, so easy to imagine things under 80 python (due to lack of decent types/more verbose community) has more of a need for those 80 chars. I think there's likely a per-project line limit that "makes sense".
erpellan 10y ago
If punch cards were 160 columns wide, we'd all be enforcing that as the maximum line width. It's arbitrary. I typically go with 'about 1/3 of my screen width' so I can develop in multiple windows without horizontally scrolling. That's a lot more than 80 chars on a 4k screen.
dozzie 10y ago
> 80 characters helps a lot [...] 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. Add the fact that there still are people who print the code on paper out there.

by zepolen 10y ago

ergo14 10y ago

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 10y ago
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/%40angular/http/src/headers.ts https://github.com/angular/angular/blob/master/modules/%40an... 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 10y ago
  > * 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.

middleclick 10y ago

I was in the camp of "I disagree with 79 character rule" when I started. However, as someone who has written lots of Python for work, I realized that it does make the code look more readable and while I used to do it initially out of compliance with the existing code, I now do it it because I like it. Does anyone else feel this way? Or I like it because I had to do it and therefore had to like it in the process.

adisbladis 10y ago
I was the same and of the opinion that this was mostly a relic of the past. Then I was assigned a project where this was enforced in the test suite and had to religiously follow pep8. It took a while to get used to but after a while the benefits (like fitting into everyone's editor configuration, cleaner list comprehensions etc) became apparent. Now I'm the one to put flake8 as a part of the test suite in any new python project :)

raverbashing 10y ago

> there is rarely a time the code can't be broken down to fit. Yes, it can. It also might end up being: a) less readable, b) uglier Resources are limited so I'd rather devote my efforts to fixing major styling problems rather than a line that goes over 3 characters Having a hard limit is overblown nitpickness (and even the 1st line of Pep8 warns you against those) Not to mention how to do line continuation involves different conflicting styles

zepolen 10y ago
Find an example in your code base where you had to go over 80 characters. find . -name '*.py' | xargs grep -n '^.\{80\}' and post it here.
- raverbashing 10y ago
  You "don't" need to go over 80 chars. But it's stupid to break a line like this in two stuff.do_something_funny(abc, def, ghi) when the limit is reached at the 3rd parameter (or worse, at the parenthesis)
- stinos 10y ago
  By that reasoning you could almost say 'find an example where you had to go over [insert arbitrary number between 50 and 100 or so]'. If the number if low enough or my screen is wide enough I could fit 4 text editor panes next to each other :] Any code could probably be broken up to match that as well. Don't get me wrong, I personally think 80 is a fine number and it's what I use myself. But making things like this hard rules for what basically are arbitrary reasons (e.g. depending on screen resolution) doesn't seem right in my book. I'm seriously not even considering doing something about a line if it's 81 characters.
- fnord123 10y ago
  Not python, but in Java, identifiers can get quite long. e.g.: "localizableRUNTIME_MODELER_PORTNAME_SERVICENAME_NAMESPACE_MISMATCH" is the longest at 66 characters. As for python, some fancy list comprehensions get rather long rather quickly. Especially if itertools are involved as you izip, etc. Or using useful variable names (i.e. not 'fcnt', 'tcnt') while destructuring as in this example from pyspark/mllib: (failure_count, test_count) = doctest.testmod(globs=globs, optionflags=doctest.ELLIPSIS) I adapted your grep to: find . -name '*.py' | xargs grep -n '^ *.\{80\}' So leading indentation doesn't mess with the results.

jammycakes 10y ago

While 80 characters may be a bit restrictive, there is a need for a hard limit of something. I've found that in the absence of a hard limit, you all too quickly end up with a codebase riddled with 250+ line monsters forcing you to scroll right and left all over the place just to get the faintest smidgen of an idea of what's going on. It's a maintenance nightmare. Meanwhile, GitHub won't show lines longer than 132 characters (on Windows) or 123 characters (on the Mac) without scrolling, no matter how wide your screen. I personally find 100 seems to strike the right balance.

rtpg 10y ago

very dependent on the language imo C tends to be terse, so easy to imagine things under 80 python (due to lack of decent types/more verbose community) has more of a need for those 80 chars. I think there's likely a per-project line limit that "makes sense".

erpellan 10y ago

If punch cards were 160 columns wide, we'd all be enforcing that as the maximum line width. It's arbitrary. I typically go with 'about 1/3 of my screen width' so I can develop in multiple windows without horizontally scrolling. That's a lot more than 80 chars on a 4k screen.

dozzie 10y ago

> 80 characters helps a lot [...] 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. Add the fact that there still are people who print the code on paper out there.