proposing max line length of 119 + enforcing it with flake8

[Tim Graham]

Ticket #23395 raised the issue that our contributing guidelines is not exactly clear regarding long lines. Currently it says,

"One big exception to PEP 8 is our preference of longer line lengths. We’re well into the 21st Century, and we have high-resolution computer screens that can fit way more than 79 characters on a screen. Don’t limit lines of code to 79 characters if it means the code looks significantly uglier or is harder to read."

I'd like to propose changing it like this:

"An exception to PEP 8 is our preference of longer line lengths. Don’t limit lines of code to 79 characters if it means the code looks significantly uglier or is harder to read. Up to 119 characters is okay as this is the width of GitHub code review; anything longer requires horizontal scrolling which makes review more difficult. This check is included when you run flake8. Documentation, comments, and docstrings should be wrapped at 79 characters."

The biggest hurdle is cleaning up the existing code as we currently have ~1700 lines longer than that. I attached an initial patch on the ticket to show how long strings can be restructured. If there is no objection, perhaps I can work with some afraid-to-commit workshop participants to divvy up the work. flake8 fixes were a big hit last time.

[Carl Meyer]

On 09/03/2014 01:47 PM, Tim Graham wrote:
> Ticket #23395 <https://code.djangoproject.com/ticket/23395> raised the

I support this change to the wording, and your sample long-line fixes
look fine.

How about just removing the sentence "An exception to PEP 8 is our
preference of longer line lengths." With recent updates to PEP 8 to
accommodate longer lines, the stated policy is no longer an exception to
PEP 8, and I think "preference of longer line lengths" is poorly worded
anyway; preference vs what? Nobody prefers longer lines to shorter ones,
all else equal (at least I'd hope not).

Carl

[Daniele Procida]

On Wed, Sep 3, 2014, Tim Graham <timog...@gmail.com> wrote:

>The biggest hurdle is cleaning up the existing code as we currently have
>~1700 lines longer than that. I attached an initial patch on the ticket to
>show how long strings can be restructured. If there is no objection,
>perhaps I can work with some afraid-to-commit workshop participants
>to divvy up the work. flake8 fixes were a big hit last time.

Sounds like a great idea, and an ideal thing for workshop participants to tackle (I have already marked the ticket, as you've probably noticed).

As for the actual length, 119 seems - for now, though who knows when GitHub will change their limits - sensible.

Thanks,

Daniele

[Aymeric Augustin]

That works for me.

Considering the amount of code that needs fixing, it isn't a big deal if the cleanup is spread over many commits.

-- 

Aymeric.

[Anssi Kääriäinen]

+1

It is a good idea to have some limit on line lengths. There are some
exceptions where longer lines improve readability, but in those rare
cases we can just use # noqa.

- Anssi

[Zach Borboa]

Looks like the line length limit on Github varies[1]. Can we use 120 as it's a nice round number?

[1] http://stackoverflow.com/questions/22207920/what-is-githubs-character-limit-or-line-length-for-viewing-files-on-github

[Zach Borboa]

Screenshot for comparison.

[Collin Anderson]

we say 119 because it's 120 minus one, just like PEP8 recommends 79 because it's 80 minus one.

It allows for one character at the beginning of the line for a plus or minus sign in a diff.

[anjul.ten]

I think we should consider the minimum character limit i.e. 113 characters for Chromium, Ubuntu based on the link shared by Zach Borboa into consideration as well.

[Dražen Odobašić]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I've created a PR [0] that applies max. line length of 119 chars to the master
branch.

Personally, on Firefox-Linux, not all 119 chars are visible on GH, as it's
highly dependant of the environment, fonts, dpi, ...

With the limit of 113 chars, there are 1051 lines that require modifications.
However, because of the way that tests are written (assertEqual) and comparing
strings, it's not possible to break the formatting of strings as it will cause
tests to fail [1]. Basically, we are stuck with disabling flake8 checks for
those lines.

I've only spent short amount of time with the codebase, but we should start
discussing how to improve "Coding style" document [2], and what kinda style
conventions to impose. I'll write an email and list of inconsistencies in the
code.

Dražen


[0] https://github.com/django/django/pull/5224
[1]
https://github.com/dodobas/django/commit/b2839a253226d5d2a30c7c9bbe3b8609413c760
f#diff-74c67aea7429ebe5e21f206f24b4418bR2297
[2]
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding
- -style/

On 03.09.2015 09:10, anjul.ten wrote:
> I think we should consider the minimum character limit i.e. 113 characters

> for Chromium, Ubuntu based on the link shared by *Zach Borboa *into
> consideration as well.
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJV6DjqAAoJEIAOBeNeJzcKqlYH/00qLzRNjtgMvuWg7HhBNibK
vCIUOwguZK8R5tUxPkKhCsx3yKmjQ7iaA3OYO6ipBS/wXnvcSPdLOlsAklgxDfwX
fgBZ0tHpAyW3Hp/frTCZYp2OvBLDXLsff0DPXopR0xsqeZPdyjTU3yJ/XKqQ7Oys
zX8Nw8cp4kvk5dffG+aCzZzzVHK5zJTIH6HoII2jzHH/6WijxJ8miLyeKcd4YdVa
ij6e7+7em0dmDTw0XUtLnbRL7yUT8A5I2TA29Qhyj2BzJkV+Zv41A91XQIPxsp8C
PuBbinfx7Z2DQ42+YFda+YYidsvVbi+Xm7Rl/Hn7/6SemlnkLJs3Ndxti26dRB8=
=fSQh
-----END PGP SIGNATURE-----