I think that reading code is different enough from reading text that I'll stick with my 100-character limit, though most lines fall well short of that (I'm not one for clever one-liners; they're much worse than dad jokes).
With code, the syntax highlighting changes the equation (to the point I now find working with code without it something of a challenge). I use a lot of alignment and whitespace for readability, and I do prefer to work vertically rather than horizontally. Comments definitely have to fit in a narrower range because doc pages.
But 80 is just too restrictive for me. (In retirement, I only ever write my own hobby code anyway, so I'm free to follow any standard that works for me. 😎)
I tried to stick to 80 columns as much as possible for a long time, but I realized that I had the tendency to use more and more very short function and variable names because of that.
Of course I try to decompose complex operations that could fit in a single line for readability and ease of maintenance, but since a few years ago, I added another practice that is sacrilege to PEP8 advocates: I align on equal signs (and colon for dicts).
It is contrary to PEP8 and makes the 80 column rule almost impossible to reasonably conform to, but since then, I find my code way, way easier to read and maintain. I generally do a pass on my fresh new code to fix PEP8 warnings and with a multiple cursor IDE (thanks PyCharm) it's done in an instant to adjust the alignment this way.
Funny that my Note for this was right after my Note about using iter(range(len(my_list))) rather than itertools.count. I don't usually post Notes about Python. 😊
Now that Python allows a trailing comma in lists (e.g. [1,2,3,]) I've gotten out of the habit, but especially in languages like C++ or Java that choke on extra commas I used that comma trick quite a bit. But I'd align the commas under that opening square bracket so that each list item starts with a delimiter. The square bracket (or opening parenthesis or curly brace) on the first item, commas on all the rest. Usually, just one space after the delimiter. The closing bracket (or parenthesis or brace) vertically aligns under all the rest.
The technique helps with the trailing comma problem when you rearrange the list, and the last item ends up somewhere in the middle. Without a comma after it.
Which with 2.5 and no ruff makes sense. It's always a matter of context. Usually people's decision make sense (if anythin, it can be nit knowing and choosinh the first thing). This is why I think the notion of best practices have been pushed to hard to the point people belive that, like in schools, there is a single best answer to problems you encounter later in life if you want an A+.
Long ago I worked with someone whose CS professor had drilled TDD into. I'm all for testing but the notion of writing just as much test code as production code was anathema to me. And I found it too easy to go down a rabbit hole of making test after test and still not really testing the system as a whole. I prefer to test at the system level and only drill down to unit tests when necessary.
I think that reading code is different enough from reading text that I'll stick with my 100-character limit, though most lines fall well short of that (I'm not one for clever one-liners; they're much worse than dad jokes).
With code, the syntax highlighting changes the equation (to the point I now find working with code without it something of a challenge). I use a lot of alignment and whitespace for readability, and I do prefer to work vertically rather than horizontally. Comments definitely have to fit in a narrower range because doc pages.
But 80 is just too restrictive for me. (In retirement, I only ever write my own hobby code anyway, so I'm free to follow any standard that works for me. 😎)
I tried to stick to 80 columns as much as possible for a long time, but I realized that I had the tendency to use more and more very short function and variable names because of that.
Of course I try to decompose complex operations that could fit in a single line for readability and ease of maintenance, but since a few years ago, I added another practice that is sacrilege to PEP8 advocates: I align on equal signs (and colon for dicts).
It is contrary to PEP8 and makes the 80 column rule almost impossible to reasonably conform to, but since then, I find my code way, way easier to read and maintain. I generally do a pass on my fresh new code to fix PEP8 warnings and with a multiple cursor IDE (thanks PyCharm) it's done in an instant to adjust the alignment this way.
To each his own I guess ;)
I still prefer my 120-character length default (thank you Pycharm) :)
Feels like the spaces vs tabs debate doesn't it?
yeah, kind of...
Only barbarians use tabs. 😂🤣😂🤣
Less than 10 years ago, I worked on a code base that not only used tabs, but also prefixed with commas all items in collections, like this:
https://imgur.com/a/5CBxju6
They were still using Python 2.5.
Edit: welp, no code block in comment. Have to screenshot
Yep, I was able to figure out what you meant. (I find the Notes versus Comments differences are one of the weirder things about Substack.)
Here's how I used to do it:
https://substack.com/@wyrdsmythe/note/c-178241988
Funny that my Note for this was right after my Note about using iter(range(len(my_list))) rather than itertools.count. I don't usually post Notes about Python. 😊
Now that Python allows a trailing comma in lists (e.g. [1,2,3,]) I've gotten out of the habit, but especially in languages like C++ or Java that choke on extra commas I used that comma trick quite a bit. But I'd align the commas under that opening square bracket so that each list item starts with a delimiter. The square bracket (or opening parenthesis or curly brace) on the first item, commas on all the rest. Usually, just one space after the delimiter. The closing bracket (or parenthesis or brace) vertically aligns under all the rest.
The technique helps with the trailing comma problem when you rearrange the list, and the last item ends up somewhere in the middle. Without a comma after it.
Which with 2.5 and no ruff makes sense. It's always a matter of context. Usually people's decision make sense (if anythin, it can be nit knowing and choosinh the first thing). This is why I think the notion of best practices have been pushed to hard to the point people belive that, like in schools, there is a single best answer to problems you encounter later in life if you want an A+.
Long ago I worked with someone whose CS professor had drilled TDD into. I'm all for testing but the notion of writing just as much test code as production code was anathema to me. And I found it too easy to go down a rabbit hole of making test after test and still not really testing the system as a whole. I prefer to test at the system level and only drill down to unit tests when necessary.
Sorry replying from a phone
Optimal Line Length in Reading : A Literature Review
https://journals.uc.edu/index.php/vl/article/view/5765