Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
To: sohcahto...@gmail.com sohcahto...@gmail.com writes: My terminals are 120 columns wide. Mine are wider. So what? Are there still people that are limiting their terminals to 80 columns? I don't know. Terminal width is not the sole reason to keep code lines within 80 columns. -- \ ΓÇ£The fundamental principle of science, the definition almost, | `\ is this: the sole test of the validity of any idea is | _o__) experiment.ΓÇ¥ ΓÇöRichard P. Feynman | Ben Finney --- SoupGate-Win32 v1.05 * Origin: SpaceSST.BBS.Fidonetnntp.gatew...@.piz.noip.me (1:249/999) --- Synchronet 3.15b-Win32 NewsLink 1.92 SpaceSST BBS Usenet Fidonet Gateway -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
To: sohcahto...@gmail.com On 12/08/2014 03:20 PM, sohcahto...@gmail.com wrote: On Sunday, December 7, 2014 6:26:01 PM UTC-8, jtan wrote: One reason why you would want max length 79 is because of working with terminals. Maybe ssh to you server and check how many spaces are consumed by a tab? In my boxes, it is usually 1 tab = 8 spaces. So perhaps just use that setting in your editor? My terminals are 120 columns wide. Are there still people that are limiting their terminals to 80 columns? If so, why? I frequently have more than just one terminal open on my xserver. I might have several terminals, or I might also have a browser or another application. And I rearrange the windows so the parts I'm interested in are showing whatever I'd like to simultaneously see. I mean, I can understand if you're running on an ancient square monitor, but I see no reason to limit your terminal to 80 columns if you're running any sort of window environment on monitor with a horizontal resolution greater than 1280. What's square got to do with anything? I have displays ranging from about 3 inches across to about 29. The size matters, not usually the pixel count (my cell phone has 1920 pixels across). Because that's how we've always done it! is a pretty reason to continue doing something. No need to throw feces around. There are several reasons besides history. 1) physical screen size, divided by the number of simultaneous windows one wants horizontally visible. 2) vision acuity. When the print gets small enough, my elderly eyes can't read it reliably. 3) Human preference and ability. Notice that large books and newspapers use multiple columns, or pictures ads to break up the page. A line beyond some length makes it hard to take it all in at once. 4) Other media. Sometimes we actually make listings on paper. If code is only going to be used by one person, then it may make sense for that person to make it as wide as the size he personally can handle, with his abilities and equipment and usage habits. But when there are multiple people, it sometimes makes sense to constrain code to the most stringent of their abilities. And one's abilities change over time, just as his equipment does. -- DaveA --- SoupGate-Win32 v1.05 * Origin: SpaceSST.BBS.Fidonetnntp.gatew...@.piz.noip.me (1:249/999) --- Synchronet 3.15b-Win32 NewsLink 1.92 SpaceSST BBS Usenet Fidonet Gateway -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
To: jtan On Mon, Dec 8, 2014 at 10:15 AM, Aahan Krish kr...@aahan.me wrote: My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* TY, Aahan On Sunday, December 7, 2014 6:26:01 PM UTC-8, jtan wrote: One reason why you would want max length 79 is because of working with terminals.á Maybe ssh to you server and check how many spaces are consumed by a tab?á In my boxes, it is usually 1 tab = 8 spaces.á So perhaps just use that setting in your editor? My terminals are 120 columns wide. Are there still people that are limiting their terminals to 80 columns? If so, why? I mean, I can understand if you're running on an ancient square monitor, but I see no reason to limit your terminal to 80 columns if you're running any sort of window environment on monitor with a horizontal resolution greater than 1280. Because that's how we've always done it! is a pretty shitty reason to continue doing something. --- SoupGate-Win32 v1.05 * Origin: SpaceSST.BBS.Fidonetnntp.gatew...@.piz.noip.me (1:249/999) --- Synchronet 3.15b-Win32 NewsLink 1.92 SpaceSST BBS Usenet Fidonet Gateway -- https://mail.python.org/mailman/listinfo/python-list
Re: Reasons for source code line length limits (was: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?)
On Sunday 07 December 2014 23:44:40 Ben Finney did opine And Gene did reply: jtan ad...@grails.asia writes: One reason why you would want max length 79 is because of working with terminals. That reason is decreasingly relevant as terminals become virtual, in a display window that can be much larger if we choose. Much more relevant is the ability to have two or even three code windows side-by-side, for comparison during a merge operation. For this purpose, a 75–80 column limit is a great help. But regardless of display technology, the biggest reason to stick to a limit like 80 or less is: reader technology. The ability for humans to comprehend long lines of text is poor, and there *is* a cognitive point beyond which it's not helpful to have longer lines. That line-length limit is different for different people, and many readers (and especially code writers) will fool themselves that they can read longer lines while unknowingly harming their comprehension. But for sure, it remains relatively constant across generations of humans, no matter how the display capacity increases. This last point about line length vs comprehension, I am glad you mentioned, Ben. I still work in assembler on smaller, narrower bus machines, and I find that the one operation on data per line of source is a great help in tracking what the code is doing, The biggest problem with that is that most assemblers format the output listing so the comments column starts at column 40 or so. This 80 column limit, purely arbitrary, often results in the printout listing being clipped off, or is line wrapped by the printer driver, severely reducing the value of the comment when you want to revisit that code later for some reason. For that reason, I generally do my assembler listing printouts with the -olandscape switch in effect. Even in the gcode I write (I have some cnc mill and lathe machines) is usually wide enough that the landscape mode for the paper copy is used. Now if one could buy 3 ring binders for landscape printouts. But ask for those at Staples and you, like the sign says, get the dumb looks for free. :( Some languages need character wasting wrappers around the variable names used, and in gcode that is a 3 or 4 character wrapper dependent on whether its to be local to the subroutine, or is globally visible from anyplace in the program. Gcode itself hasn't a line length limit that matters, 32k IIRC, but I still like to limit data manipulations to 5 additions and maybe a couple of mul's per line. However for me, that has comprehension problems for the exact reason that it winds up doing far more data manipulation per line, so I will often use a local variable, with one manipulation per line, a heck of a lot easier to understand even 2 weeks later as my short term memory isn't as good as the years go by, and there are now 80 of them. So it is a valid concern Ben, thanks for mentioning it. I have an intense dislike for folks who think they should build an empire state building in one line of code. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
- Original Message - From: Aahan Krish kr...@aahan.me To: python-list@python.org Sent: Monday, 8 December, 2014 3:15:43 AM Subject: Maintaining Maximum Line Length When Using Tabs Instead of Spaces? My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* TY, Aahan You simply need to define the standard width for you tab display. 4 is very common. Those in your team who want to use a different display (3 flowers for instance) can, but they'll have to deal with the 79 limit by themselves which can be tricky. Note that the 79 limit is a legacy value from the time where code was developed in 80 characters terminals with names not exceeding 8 characters (by convention). Given the number of monitors you have and their width, you may extend this limit. For instance, I can easily make a 3 files merge with 160 chars per line without problem. Considering the current state of most developer hardware, a limit around 100 char per line is most of the time a better choice. Remember that breaking a line of 81 characters often leads to readability issue for no (modern) reason. JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On Mon, Dec 8, 2014 at 10:15 AM, Aahan Krish kr...@aahan.me wrote: My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* TY, Aahan On Sunday, December 7, 2014 6:26:01 PM UTC-8, jtan wrote: One reason why you would want max length 79 is because of working with terminals. Maybe ssh to you server and check how many spaces are consumed by a tab? In my boxes, it is usually 1 tab = 8 spaces. So perhaps just use that setting in your editor? My terminals are 120 columns wide. Are there still people that are limiting their terminals to 80 columns? If so, why? I mean, I can understand if you're running on an ancient square monitor, but I see no reason to limit your terminal to 80 columns if you're running any sort of window environment on monitor with a horizontal resolution greater than 1280. Because that's how we've always done it! is a pretty shitty reason to continue doing something. -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
sohcahto...@gmail.com writes: My terminals are 120 columns wide. Mine are wider. So what? Are there still people that are limiting their terminals to 80 columns? I don't know. Terminal width is not the sole reason to keep code lines within 80 columns. -- \ “The fundamental principle of science, the definition almost, | `\ is this: the sole test of the validity of any idea is | _o__) experiment.” —Richard P. Feynman | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On 12/08/2014 03:20 PM, sohcahto...@gmail.com wrote: On Sunday, December 7, 2014 6:26:01 PM UTC-8, jtan wrote: One reason why you would want max length 79 is because of working with terminals. Maybe ssh to you server and check how many spaces are consumed by a tab? In my boxes, it is usually 1 tab = 8 spaces. So perhaps just use that setting in your editor? My terminals are 120 columns wide. Are there still people that are limiting their terminals to 80 columns? If so, why? I frequently have more than just one terminal open on my xserver. I might have several terminals, or I might also have a browser or another application. And I rearrange the windows so the parts I'm interested in are showing whatever I'd like to simultaneously see. I mean, I can understand if you're running on an ancient square monitor, but I see no reason to limit your terminal to 80 columns if you're running any sort of window environment on monitor with a horizontal resolution greater than 1280. What's square got to do with anything? I have displays ranging from about 3 inches across to about 29. The size matters, not usually the pixel count (my cell phone has 1920 pixels across). Because that's how we've always done it! is a pretty reason to continue doing something. No need to throw feces around. There are several reasons besides history. 1) physical screen size, divided by the number of simultaneous windows one wants horizontally visible. 2) vision acuity. When the print gets small enough, my elderly eyes can't read it reliably. 3) Human preference and ability. Notice that large books and newspapers use multiple columns, or pictures ads to break up the page. A line beyond some length makes it hard to take it all in at once. 4) Other media. Sometimes we actually make listings on paper. If code is only going to be used by one person, then it may make sense for that person to make it as wide as the size he personally can handle, with his abilities and equipment and usage habits. But when there are multiple people, it sometimes makes sense to constrain code to the most stringent of their abilities. And one's abilities change over time, just as his equipment does. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* TY, Aahan -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish kr...@aahan.me wrote: My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. Easy: You stop fretting about 79 characters. :) If your policy is lines are no more than 80-100 characters long, then the difference between 4-space tabs and 8-space won't break stuff unless it was already marginal. So if you run 4-space (or 2-space) indentation, you just make sure you keep your lines to the lower end of the limit. Even better, don't quibble about any sort of specific limit, and just have a policy of don't make stuff so long that it's unreadable, and don't put silly arbitrary rules on your programmers. That's my policy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
One reason why you would want max length 79 is because of working with terminals. Maybe ssh to you server and check how many spaces are consumed by a tab? In my boxes, it is usually 1 tab = 8 spaces. So perhaps just use that setting in your editor? On Mon, Dec 8, 2014 at 10:15 AM, Aahan Krish kr...@aahan.me wrote: My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* TY, Aahan -- https://mail.python.org/mailman/listinfo/python-list -- Freelance Grails http://grails.asia/ and Java http://javadevnotes.com/ developer -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On Mon, Dec 8, 2014 at 10:23 AM, Chris Angelico ros...@gmail.com wrote: On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish kr...@aahan.me wrote: My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. Easy: You stop fretting about 79 characters. :) I agree with this. Just settle with your team what's your standard and have similar IDE settings. If your policy is lines are no more than 80-100 characters long, then the difference between 4-space tabs and 8-space won't break stuff unless it was already marginal. So if you run 4-space (or 2-space) indentation, you just make sure you keep your lines to the lower end of the limit. Even better, don't quibble about any sort of specific limit, and just have a policy of don't make stuff so long that it's unreadable, and don't put silly arbitrary rules on your programmers. That's my policy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- Freelance Grails http://grails.asia/ and Java http://javadevnotes.com/ developer -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On 12/7/14 9:15 PM, Aahan Krish wrote: My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* Pointing out that spaces make more sense is not a flame war. You are here asking how to deal with the variability inherent in tabs. Spaces don't have that problem. That is not flaming. That's solving your problem. I'm curious why you care about the 79 characters part of PEP8 if you don't care about the use spaces part of PEP8. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
Hi Ned, I'm curious why you care about the 79 characters part of PEP8 if you don't care about the use spaces part of PEP8. It's just that I don't like arbitrary rules. IMHO, spaces aren't better than tabs, and people should refrain from saying that. Both have their fair bit of disadvantages and it finally comes down to personal/team preference or consistency. I like tabs because they are flexible. As of now I am still considering spaces for two reasons—(1) maintaining a standard line-length of 79-120 characters; (2) Even if I use tabs, I may need spaces for aligning. I have no major projects now, so I am free to decide, and am taking my time for a well-thought decision. As for why I care the 79 chars part of PEP 8: - Coding in terminals and VIM with multiple windows open. - Avoiding horizontal scrollbars for code blocks on the web; GitHub for instance. E.g. https://github.com/torvalds/linux/blob/master/kernel/async.c -- That is good! - Readability; The same reason why people suggest short paragraphs, i.e. allow readers to quickly go through your content, or in my case, code. Best, Aahan -- https://mail.python.org/mailman/listinfo/python-list
Reasons for source code line length limits (was: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?)
jtan ad...@grails.asia writes: One reason why you would want max length 79 is because of working with terminals. That reason is decreasingly relevant as terminals become virtual, in a display window that can be much larger if we choose. Much more relevant is the ability to have two or even three code windows side-by-side, for comparison during a merge operation. For this purpose, a 75–80 column limit is a great help. But regardless of display technology, the biggest reason to stick to a limit like 80 or less is: reader technology. The ability for humans to comprehend long lines of text is poor, and there *is* a cognitive point beyond which it's not helpful to have longer lines. That line-length limit is different for different people, and many readers (and especially code writers) will fool themselves that they can read longer lines while unknowingly harming their comprehension. But for sure, it remains relatively constant across generations of humans, no matter how the display capacity increases. -- \ “If you can't annoy somebody there is little point in writing.” | `\—Kingsley Amis | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On Mon, Dec 8, 2014 at 3:39 PM, Aahan Krish kr...@aahan.me wrote: As for why I care the 79 chars part of PEP 8: - Coding in terminals and VIM with multiple windows open. Then measure your width with tabs set to 8 spaces, and nothing else matters. Otherwise, go back to your previous statement about avoiding arbitrary rules, maximize your terminal window (let's see, if I hit Alt-F10 on my Xfce system, I get a terminal window that's 51 rows, 190 columns; F11 increases that to 55 rows), and ignore the precise counts. All your other points are just as valid with 82 characters as with 79, and pretty much as valid with anything up to about 100-120. - Avoiding horizontal scrollbars for code blocks on the web; GitHub for instance. E.g. https://github.com/torvalds/linux/blob/master/kernel/async.c -- That is good! It goes to 100 frequently, and I found one line that went to 126... if that's your idea of good, then I think going as far as 100 in your own code shouldn't be a problem. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Reasons for source code line length limits (was: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?)
On Mon, Dec 8, 2014 at 3:44 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: But regardless of display technology, the biggest reason to stick to a limit like 80 or less is: reader technology. The ability for humans to comprehend long lines of text is poor, and there *is* a cognitive point beyond which it's not helpful to have longer lines. This is true. However, the human eye tends to ignore leading indentation to some degree, so in terms of the original question (which referred to tabs vs spaces and how that interacts with the line length limit), it's even less important to worry about exact character counts. Sure, a 500-character line is less readable than a 75-character line. But how much difference is there between 79 and, say, 90? I'd say there's more variation between different people than that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
Chris Angelico ros...@gmail.com writes: On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish kr...@aahan.me wrote: My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. Easy: You stop fretting about 79 characters. :) The question is a good one, especially when one considers the use of an automated test to detect lines which violate an agreed style guide. If your policy is lines are no more than 80-100 characters long, Such a policy still needs to know how many columns a U+0009 TAB character is to be counted, if an automated test is to be useful. You may not find value in such an automated “does this code meet the agreed style guide?” test, but many do. Perhaps the OP is one. -- \ “How wonderful that we have met with a paradox. Now we have | `\some hope of making progress.” —Niels Bohr | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
Aahan Krish kr...@aahan.me writes: It's just that I don't like arbitrary rules. IMHO, spaces aren't better than tabs, and people should refrain from saying that. Simplicity has value. The rule “use four spaces for indentation” is simple to stick to, and simple to obtain sane display results by default. Using U+0009 characters for indentation is objectively more complex, because of the addition of all the special treatment of U+0009 characters, and especially the admonitions needed to readers not to use the attractive editor features of customising U+0009 rendering. So, you may decide the simplicity is less valuable than the ability to change the rendering of this special U+0009 character. But, if one values that simplicity, then U+0020 characters *are* better than U+0009 characters for indentation. So, no, I will not refrain from saying that. -- \ “You can be a victor without having victims.” —Harriet Woods, | `\ 1927–2007 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
