|
Wrapping code at 80 columns?
The title says it all. What coding standards say in this regard in your organization? Your personal preferences?
A programmer
Wednesday, March 31, 2004
Screens, right, are a lot wider than they are long.
My personal preference is to tell people to get an editor that can handle more than 80 columns and to get a screen with a decent resolution.
Oh, and to use a dev environment that doesn't fill 90% of the screen with annoying tat. Yes, Visual Studio, I'm looking at you.
Katie Lucas
Wednesday, March 31, 2004
You can enter full screen mode in Visual Studio or just hide the windows that you do not need.
Matt Watson
Wednesday, March 31, 2004
80, and I happen to like it that way. Yes, Katie, I'm looking at you :-)
I find it really useful to have "other stuff" visible as well, so taking up the whole screen with code is a no-no for me. Besides, when you print it, and sometimes you need to, paper, right, is a lot longer than it is wide :-p
Wednesday, March 31, 2004
My Java User Group, The New England Java Users Group, created a Java coding standards document and adopted 80 columns as a style. There was quite a bit of debate on this. Those for, myself included, feel that 80 columns helps with readablilty. The minority thought that with large monitors and huge resolutions higher numbers of columns are acceptable. You can get a copy for yourself of the document:
http://www.nejug.org/standards.jsp
I prefer 80 for two reasons. First is readabilty. I think the brain can handle 80 columns easier even if the entire line is in view. Second, if you ever need to view the source from the command line, anything over 80 can get messy.
Bill Rushmore
Wednesday, March 31, 2004
I keep it at 80 columns - it fits nicely on screen and on paper.
I might not have settled on 80 columns if I used a higher screen resolution. I use a screen resolution of 800x600 'cause my eyes are too old and tired to look at anything smaller for extended periods of time.
bpd
Wednesday, March 31, 2004
80 columns, usually, sometimes less.
Sometimes, I don't work with the editor maximized, and I tend to use only the space I have available (e.g., 40-50 columns).
Paulo Caetano
Wednesday, March 31, 2004
One of my biggest pet peeves! I work at a place where lines just go on and on and on, and it drives me nuts to have to scroll over - even with a high resolution screen. Random thoughts:
* My brain does wrap around the semantics of long lines much better if I can see the whole of it in 80 columns.
* If a line is much longer than 160 characters, I start to think I'm not writing code as tersely or as clearly as I should.
* There's no cost to wrapping text at 80 characters, and there is certainly potential benefit - so, it seems to me that a cost-benefit analysis would certainly suggest that developers wrap the code.
* I agree with the points about printing text, or having to read it in DOS mode, or perhaps telnetting to a Unix box.
888
anon
Wednesday, March 31, 2004
What possible reason is there to have a line longer than about 80-100 characters anyway? Isn't that just bad programming regardless of screen resolution?
Mr Jack
Wednesday, March 31, 2004
Let's say your company goes all the way back to C64, would you have kept to the width standard of that era? No right? You should stick to a standard in the end, but the standard should get with the times. There was a time for 80, but I think most company can get away with a slightly wider width. Should it be 132? Or some terminal standard? No, it should be based on the largest number of mono-space characters possible of the 5 most standard console / coding type face (and of these, the 5 most common font size) on a 1024 x 768 or 1280 x 1024 screen. Round it to the 10th characters. Either calculation should give you a standard something you won't mind holding on to for a good 3-6 years.
Li-fan Chen
Wednesday, March 31, 2004
> largest number of mono-space characters possible
I meant smallest.
Li-fan Chen
Wednesday, March 31, 2004
I tend to keep two edit windows side by side, and 80 columns facilitates this. Also, as an emacs user, emacs naturally opens at 80 columns wide. And command shells are naturally 80 column wide when I want to quickly look at some code without pulling it into an editor. Also, as mentioned, 80 columns prints nicely.
But, hey, your standards should reflect your work environment. If you do all your code viewing/editing with an editor and screen and approach that facilitates wider lines, then there is no reason for you to adjust your standards just to keep me happy (since we don't work together and I don't have to use your code). Supporting the least common denominator is great, as long as you limit yourself to the common denominators in your environment, and not the wild (like those great 16 color, 40 by 25 C64 screens that we should all still be using!)
madking
Wednesday, March 31, 2004
Ok, I'll jump in. Our (very loose) coding standard is generally to wrap lines at 120 characters, but there are many cases where we don't, and I think there are some good reasons why. These are by no means flawless reasons, but I think they should be considered:
- Sometimes the code that ends up over the edge really isn't terribly important. Logging statements, for example, can be relatively long (cause we want to capture the important information in the logs), but not terribly interesting to a developer. In these cases, the beginning of the line indicates that it's a logging statement, and the full text of the log statement generally isn't terribly helpful to someone trying to understand the code.
- Sometimes vertical space is more valuable than horizontal space when writing code, and longer lines lets me trade one for the other. I'd often rather see the entire structure of my (method, loop, other control structure) on one page than have to page back and forth.
- I'd usually rather have long lines than short variable/method names - if the vertical space is valuable, another way to split fewer lines is to have shorter names for everything, which can hurt understandability more than long lines can.
Screen real estate isn't usually an overly-constrained resource (in my environment, anyway), so one can often have code that fits in all dimensions without having to make any code-layout tradeoffs, but having hard limits often isn't useful, either.
schmoe
Wednesday, March 31, 2004
I use Profont (thanks Joel!) set at 9 point on 1280x960, which would theoretically let me display about 200 columns, but the crappy stinkin' stock version of vi that's included with Solaris is apparently limited to 163 columns. (Note to editor partisans: This is not to knock vi in general, just this annoyingly limited implementation of it). But even so, if I have a long line (for example, if I'm combining many sed edits in a single step) I generally use the continuation character (i.e. escape the CR with a backslash) and then indent each clause (for example, each "-e s/old/new/g") so as to align nicely with the line above. (I'd post an example but the effect would be lost because of the proportionally-spaced font here.)
Does anybody know if the 80-column convention originated with IBM's 24x80 standard for 3270 terminals, or did it predate that?
- former car owner in Queens
Wednesday, March 31, 2004
Coding standards should not contain arbitary restrictions, at all. 132 is just as bad as 80, and just as bad as 71 or 93.
Short lines should be prefered because they are more intelligable. In any case, I don't use mono-spaced fonts for programming anymore - it's just another relic of the twentieth century.
Mr Jack
Wednesday, March 31, 2004
I second schmoe, basically, make the most intelligent decision you can on this issue and stick with it. Most programmers can cope.
Li-fan Chen
Wednesday, March 31, 2004
>> "I don't use mono-spaced fonts for programming anymore - it's just another relic of the twentieth century."
Auuuuggghh! This would drive me absolutely insane. I mean, more power to you if this is your preference, but I gotta think this would drive most to madness. MA-A-A-A-ADDNESS!!!!!
anon
Wednesday, March 31, 2004
We encougage lines of "no more than approximately 80 characters". It should be a soft limit. I have seen people do really wacky things (like eschewing indentation) to keep lines below some limit.
Often, the 80 char limit is adopted because people don't know how to use their software (e.g. setting tabs in vi or the width of telnet screens).
njkayaker
Wednesday, March 31, 2004
The 80 column standard for punch cards goes back to 1928 (according to some web page that Google found). It may be an old standard, but seems to be a good one. With big 20" screens available today it is possible to make really wide editing screens. I occasionally make wider edit windows, but seldom see much advantage to it.
It is nice to be able to make longer edit windows. Sometimes I wonder how I ever got any coding done with those 24 line VT-100 terminals.
mackinac
Wednesday, March 31, 2004
Jeez, I'm just getting used to lower cased COBOL and y'all want to go and "standardized" 80+ characters a line.
Kero
Wednesday, March 31, 2004
Someone mentioned above that they couldn't use a resolution higher than 800x600 because their eyes were too old.
I just wanted to follow up by saying that instead of using 800x600, use the highest resolution setting you have (that still supports the refresh rate you get at 800x600), and then crank up the text size so it's the same as what you had before. This way you get text that's the same size, but you get more detail in that text. Your eyes will thank you.
Wednesday, March 31, 2004
Two points.
1) If you ever need to diff two source files on a single monitor, you'll appreciate if the lines wrap at 80 characters.
2) Many long statements perform more than one operation and would be more readable if split into separate steps with intermediate results assigned to temporary variables.
Big B
Wednesday, March 31, 2004
> I just wanted to follow up by saying that instead of using 800x600,
> use the highest resolution setting you have (that still supports the
> refresh rate you get at 800x600), and then crank up the text size so
> it's the same as what you had before. This way you get text that's the
> same size, but you get more detail in that text. Your eyes will thank
> you.
that depends: usually as you get older you notice flicker a lot more. In other words, not only does your vision decay, but also your postprocessing. Not many people have monitors that can do 1280x960 at 100Hz, and some people need that (or more).
John Lenton
Wednesday, March 31, 2004
Mr. Jack, why are you opposed to monospace fonts?
I am in favor of them for two reasons, easy to line up code on multiple lines for readability, and you are less likely to confuse two letters for one, like "rn" and "m".
What do you see as the case against monospace?
madking
Wednesday, March 31, 2004
Yeah the disadvantages of >80 char is many.. so if you can make sure everyone can be comfortable with that limit, please do so.
Li-fan Chen
Wednesday, March 31, 2004
Big B's comment about long statements is a rational basis for reducing line lengths.
njkayaker
Wednesday, March 31, 2004
A "statement" on one line is more readable than the same statement that wraps through a bunch of lines. But, text in the first ~100 characters of a display is more readable than text way out there.
So, when I'm coding, if it's stuff that needs to get read to understand the code (like parameters to a function, etc.) I'll wrap at around 100 lines (give or take to find a good break point). But if it's stuff that doesn't need to get read (like long logging strings as someone above aludes to), I'll let it go out waaay long.
At least that's what works for me. I agree with the comment about temporary variables too. Compilers are smart enough to optimize them away, and they do improve readability quite a bit (especially if they're given descriptive names.)
Michael Kale
Wednesday, March 31, 2004
I'm concerned that so many people seem to have code that extends beyond 80 columns.
What type of statement are you writing?
I develop (mainly) in C on Windows and Linux platforms, have tabs set every 8 characters, and over 90% of my code lines are well within 80 characters.
HeWhoMustBeConfused
Thursday, April 1, 2004
I use column 78 for wrapping. It's much better than 80 :)
Just a reader (usually)
Thursday, April 1, 2004
I'm trying out a new coding style:
DeviceServerShared.DeviceServerConfiguration device_server_configuration = DeviceServer.DeviceServerLocalStorage.singleton.get_configuration();
Christopher Wells
Thursday, April 1, 2004
I wouldn't actually say I'm opposed to monospaced fonts as such. I just find variable spaced fonts much more readable (and the studies will back me up, although admittedly not applied to programming), and more asthetically pleasing. I'm also not aware of any advantages of monospaced fonts.
I got the idea from Bjarne Stroustrup, in fact, the 3rd edition of The C++ Programming Language uses them, and I decided to try it out. It took me about a day to get used to and I'd never go back.
You do need to pick a good font with clear differences between rn and m and i, l, I and 1; but such fonts do exist. I use 9pt Verdana myself.
Mr Jack
Thursday, April 1, 2004
I use column 110 for wrapping. I wish I could find an addon for VS.Net 2003 that would add a vertical line at the column you specify. Other IDE's have this, I'm surprised MS didn't include this.
Craig
Wednesday, July 7, 2004
 Recent Topics
Fog Creek Home
| 
