| Re: [stellation-res] Source code line length |
On Mon, 2002-09-09 at 09:58, Jonathan Gossage wrote: > In a recent posting, Florin mentioned that he would like to see source code > line lengths restricted to 78 characters to allow viewing on small screens. > The other place where this rule can help is when printing source code. I rarely print code, but when I do, I print it landscape. > As an experiment over the weekend, I tried seeing what it would take to keep > Stellation code within this limit and came up with several readability > problems. I found that it was normally possible to find some format that > would allow the code to be restricted to a 78 column width, but what would > happen is that a statement that started as a single line could wind up > becoming 4 or 5 lines and be very difficult to follow the flow because of > the unnatural structure of the statement. For me, personally, this can be a big problem. When things break unnaturally and stretch into long verticals, it becomes quite hard for me to follow. > Another related problem if this limit is to be enforced is the the Eclipse > Java editor uses a proportional font by default which means that code that > looks OK in Eclipse may not look so good in another editor that uses > mono-spaced fonts. This is something that really bugs me about the Eclipse default configuration. I *hate* using proportional width fonts for programming. When configuring Eclipse, I always switch to a fixed-width font. Personally, I like lucidatypewriter. > One change to the current coding standards that could help considerably if > we chose to follow this guideline would be to make the tab size two > characters instead of four. With the current style, indentation can rapidly > chew up valuable screen space on the left hand side. As an experiment, I just tried switching the tab width to 2, and reformatting TextUtils.java. (I chose that file because it's one of the hardest to follow in the system: it's got the implementation of some extremely complicated algorithms, which had to be implemented using some very unpleasant data structures in order to bound its memory usage.) I'll attach a copy of it to the end of this message. I find it *very* difficult to read with tabs set to 2. There isn't enough visible shift between indent levels. In particular, in some of the complex control flows (e.g., inside of mergeChanges), I can't easily tell where one case ends and another one begins - the conditional line that separates them isn't visible enough when it's only backdented two spaces. > I think it is woth discussing these issues and coming to a consensus on > whether to include them in the Stellation coding standards. > > >From a personal point of view, I don't hold a strong opinion since all my > computers at home have large screens and I never print source code. However > there would be one benefit from my point of view in that this limit would > make it easier to tile several files in the Eclipse editor. I actually see the opposite problem. That is, I'm using Eclipse on a 1024x768 laptop. In Eclipse, the way I arrange my screen, I can get 98 columns in the text editor. So splitting into two side-by-side editors isn't an option. But I do vertical stacks of two or three editors all the time. Breaking lines of code so that they take more vertical space is a problem for vertical stacking of windows. > The other significant benefit is that it makes the code base easier to work > with on resource constrained machines. The downside is that code can rapidly > become more difficult to read because it winds up being spread across more > lines vertically. > > What do you people think? I don't feel particularly strongly about it, but I'd prefer to allow lines to go wider than 78 characters. As I said, I find it hard to read long split lines, and we've already got a lot of those using 98 character lines. -Mark -- Mark Craig Chu-Carroll, IBM T.J. Watson Research Center *** The Stellation project: Advanced SCM for Collaboration *** http://www.eclipse.org/stellation *** Work Email: mcc@xxxxxxxxxxxxxx ------- Personal Email: markcc@xxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part