Jun-17-2019, 06:49 PM
"Limit all lines to a maximum of 79 characters" --PEP8
more text even urges limiting the width to 72 characters.
this is one thing i definitely will no longer follow. ironically, i was quite
strict about it as a C programmer. but i kept having trouble with it, especially
as i was moving to using more meaningful (longer) variable names. i started out
following this in Python. but it turned to be at least as much, if not more,
troublesome. it forced excess continuations, which hurt readability.
yes, older terminal screens needed this. but wider ones have been readily
available since then. and i find that reading 2 sources of code side-by-side,
especially when restricted in width, which can make some code continue to
another line when other code does not get continued, is very hard to do
(so much so that i find i never do this). better would be an editing tool that
can interleaving the 2 sources of code intelligently, such as by indentation
pattern, which can match up a different number of lines of code that
side-by-side can never possibly do.
ultimately, in many ways, i find readability is improved by not having this
limitation. i won't even limit it to 99 characters as PEP8 suggests deeper in
its discussion. what i will be doing is looking things over, more, if lines get
longer, especially if they exceed 160 characters. my terminal display goes all
the way to 172 characters, now. while i will try to keep lines reasonably short,
i will have no hard limits, not even at 172.
i have written a (simple enough that you can do it, too) script that tells me
the width of any ASCII or UTF8 file. you might want to use such a tool before
deciding how (or if) to display files from me.
more text even urges limiting the width to 72 characters.
this is one thing i definitely will no longer follow. ironically, i was quite
strict about it as a C programmer. but i kept having trouble with it, especially
as i was moving to using more meaningful (longer) variable names. i started out
following this in Python. but it turned to be at least as much, if not more,
troublesome. it forced excess continuations, which hurt readability.
yes, older terminal screens needed this. but wider ones have been readily
available since then. and i find that reading 2 sources of code side-by-side,
especially when restricted in width, which can make some code continue to
another line when other code does not get continued, is very hard to do
(so much so that i find i never do this). better would be an editing tool that
can interleaving the 2 sources of code intelligently, such as by indentation
pattern, which can match up a different number of lines of code that
side-by-side can never possibly do.
ultimately, in many ways, i find readability is improved by not having this
limitation. i won't even limit it to 99 characters as PEP8 suggests deeper in
its discussion. what i will be doing is looking things over, more, if lines get
longer, especially if they exceed 160 characters. my terminal display goes all
the way to 172 characters, now. while i will try to keep lines reasonably short,
i will have no hard limits, not even at 172.
i have written a (simple enough that you can do it, too) script that tells me
the width of any ASCII or UTF8 file. you might want to use such a tool before
deciding how (or if) to display files from me.