PEP 8 : Maximum line Length :

[Chris Angelico]

On Fri, May 16, 2014 at 12:36 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> You and I could have opened the same C file. Only you see:
>
>    #include <stdio.h>
>
>    int                                       +--------------------+
>    main ( int     argc,                      | My first C program |
>           char *const argv[] )               +--------------------+
>    {
>            (void) printf( "Hello world\n" );
>
>            return(0);
>    }
>
> while I see:
>
>    #include <stdio.h>
>
>    /* My first C program */
>    int main(int argc, char *const argv[]) {
>      printf("Hello world\n");
>      return 0;
>    }

Well no, for two reasons. Firstly, I think the first one looks
disgusting, so even if I had that feature, I wouldn't use it like that
:)

But more importantly: You can already do that sort of thing, and it's
a bad idea. Maybe there aren't any text editors that can do it, but
you can use source control that way. (I'm going to use git as my
example, as I don't know how it's done in hg or any other; but I'm
sure it won't be hard.) You just tell git that these files (probably
"files matching glob *.c") are to be reformatted, and provide two
commands: one that cleans a file prior to it going into source
control, and one that "smudges" it at the other end. So you could
simply write a code reformatter and register it as your smudge
command, and (in the interests of readable diffs) have some
standardized reformatter as the clean command. Voila! You now can
check out my code with your formatting.

Which brings me to the second reason for not doing this. That
clean/smudge operation *destroys information*. Once you enforce code
formatting like that, you violate PEP 8's "rule zero": sometimes, it's
better to break the rules. Sometimes, your nice code reformatting
operation will actually make the program worse... and there'll be no
way for you to get back from that.

Not to mention that any reformatting that inserts or deletes lines is
a pain for debugging. "Line 42" on your screen and "Line 42" in the
traceback won't be the same thing any more. If I run your code and
give you an exception trace, you'll have to check out my version of
the code to be able to understand anything. Theoretically that could
be solved (eg you absolutely always run the checked-in version - of
course, that assumes that everyone's smudge and clean will perfectly
recreate the exact same output), but even with editor support, where
you'd move the cursor around and the line number would go berserk
(press down-arrow three times and the line number goes 5, 6, 6, 10),
it would be a pain.

Code is a text file. So is music (I use GNU LilyPond, and everything
works like code). So is data, in many many cases. So is configuration,
often, although some programs prefer to work with an opaque format.
About the only thing that really definitely shouldn't be massaged into
text is actual 2D images. Can you turn this into a few lines of code?

https://lh3.googleusercontent.com/-_8upQkJcvjE/UhTJlDzW3ZI/AAAAAAAABU8/QvExuUq47dI/s512/DSCF7600.JPG

Pretty much everything else, though, works better as plain text.

ChrisA