Quote those studies, then, please. It sounds like it won't apply here; the vast majority of lines are _not_ that long, obviously, and when you linebreak more, you get other disadvantages: More lines, and because of that, logically adjacent features drift apart, making it harder to visually make the link. For example, the closing brace starts drifting away from a matching open brace. It's also code; code is rarely read like a book. What you're quoting sounds like research about the optimal horizontal page length for a novel.
For example, method signatures with a lot of parameters tend to grow long quickly, but adding a line continuation thoroughly screws up the indentation (just think about it - your method signature is a mix of indent X and X+2, but the content is all X+1. That really looks weird. I tend to include a blank line just to make it a bit less jarring, but the problem doesn't go away), and I very very rarely need to read the whole thing when I'm reading through code. If I really do need to read the whole thing, I'll gladly horizontally scroll (with the keyboard, of course). 132 is not way too wide for coding on a laptop, as I frequently code on a laptop myself. It might be too wide for a netbook, but coding on a netbook is not something I make a habit of. >From my experience, many organizations settle on standards based solely on outdated and overly fussy code style guides. For example, many organizations settle on a rule that all ifs, whiles and fors must always use a block and must never use a single statement (i.e. if (x == null) return 0; runs afoul of the style guide), but in practice I find single-statement vastly more readable provided the statement that follows is very simple. As a result, I tend not to take "Many people do it like this" as a logical argument. it reeks of Argumentum ad Populum to me. On Oct 13, 10:56 pm, Cédric Beust ♔ <[email protected]> wrote: > Long columns can also slow down your reading speed. > > Studies show that past a certain number of columns, you read text a lot > slower because your eyes need to spend more time doing the "carriage return > + line feed" and then need to spend additional time locating the beginning > of the next line. This is not linear (meaning: past a certain number of > columns, reading speed drops sharply). > > I also find that 132 columns is way too wide for coding on a laptop, which I > do fairly often, and also to conduct code reviews and review diffs in > browsers or in Eclipse. There's also printing, for people who are into that. > > From my experience, organizations seem to settle on column lengths between > 80 and 100 characters. > > -- > Cédric > > On Wed, Oct 13, 2010 at 1:32 PM, Reinier Zwitserloot > <[email protected]>wrote: > > > > > > > > > > > We experimented with a short line length in order to facilitate seeing > > 2 files at once but we didn't find the benefits worth the hassle. > > > I'll gladly put in the effort to reformat a patch, or look the other > > way and accept one with a different code style, if its cool enough. > > > On Oct 13, 5:28 pm, B Smith-Mannschott <[email protected]> wrote: > > > On Wed, Oct 13, 2010 at 16:05, Reinier Zwitserloot <[email protected]> > > wrote: > > > > Trivial style whining? For serious? > > > > Hey, it's your project, so whatever it is, it is. I'll just explain > > > your conventions to Emacs. It may sulk a little, but I'm sure it'll > > > get over it. > > > > > I'm sure your editor has an auto-format feature of some sort. The tab > > > > style is OTTS, which means that, whatever tabstop you've configured > > > > your editor on, the indents never look weird. I've got a massive > > > > screen at home, as do the other core lombok contributors. Why handicap > > > > ourselves? > > > > I often view two buffers next to each other. This useful when editing > > > or diffing. As it happens, 80 columns means I can do this even on my > > > netbook (1024 pixels wide). To do so at 132 columns would require > > > roughly 1600 pixles horizontally, and most of that space would be > > > empty because line length is highly variable. So, I'm not really sure > > > who's handicapping themselves here. *shrug*. > > > > > I would have expected you to fall over our liberal use of > > > > one-line if and for statements, which an auto-formatter can't fix :P > > > > Yea, I saw the: > > > > if (...) for (...) { > > > blah > > > } > > > > stuff. Unusual, but reads pretty well. It made me think of Wirth > > > condensed style. ;-) Except, no, WCS is in a universe of its own: > > > > procedure GetFileName(uno: integer; var name: array of char); > > > var i: integer; ch: char; > > > begin i := 0; > > > loop ch := UT[uno].name[i]; > > > if ch = 0X then exit end; > > > name[i] := ch; inc(i) > > > end; > > > ... > > > end GetFileName; > > > > but, that's neither here nor there. > > > > using an auto-formatter is a non-solution as it would make submitting > > > patches impossible. But then, using hard tabs kind of kills that > > > anyway, at least via e-mail. Good thing we have github. > > > > > The booleans are a hold-over from an old mechanism which is now > > > > virtually never used. We're rewriting this part of the API. We've > > > > written our own much nicer API for manipulating an AST (it's on > > > > github, at lombok.ast), and we're integrating this into lombok proper. > > > > That makes sense. I saw lombok.ast, but wasn't clear how it fit > > > together with the rest. Sounds like the Right Thing. I'll have a look. > > > > > That way you only need to write a transformer once, instead of the > > > > current status quo (once PER platform. Currently there are 2 > > > > platforms, javac/netbeans and ecj/eclipse, though we want to add > > > > IntelliJ's parser to this eventually), and the API is documented (and > > > > much, _much_ nicer). > > > > Ah, I hadn't noticed the once-per-platform bit. I guess I haven't dug > > > deep enough. > > > > > FWIW, our plan for builders is to offer some sort of @Builder > > > > annotation which creates the works: A builder class, builder() and > > > > make() methods, field-named methods (just firstName(...), not > > > > setFirstName), which return the builder, and all that. When going > > > > through all that effort there's not much point in our opinion of > > > > keeping the class itself filled with setters, i.e: It makes more sense > > > > to make the class itself immutable. > > > > > On Oct 13, 8:21 am, B Smith-Mannschott <[email protected]> wrote: > > > >> On Tue, Oct 12, 2010 at 23:59, Reinier Zwitserloot < > > [email protected]> wrote: > > > >> > Rolling your own lombok plugin to produce builder pattern style > > stuff > > > >> > is trivial. > > > > >> 132 columns and hard tabs? for serious? > > > > >> Well I dove in at HandleData and am now scratching around in > > > >> HandleGetter. It's about as I expected, considering that it's > > > >> manipulating a JavaC's private AST in Java. > > > > >> The obsession with returning booleans for everywhere confused me at > > > >> first. For example, createGetterForField returns boolean, but in fact, > > > >> in only ever returns true, which is good, since createGetterForFields > > > >> completely ignores all the booleans returned by createGetterForField > > > >> and just returns its own 'true', hard coded. Who needs that? > > > > >> Really, it's just about the public handle(...) method returning a > > > >> boolean (a success value of some kind, I imagine), and your probably > > > >> just trying to be consistent [1], since generateGetterForType actually > > > >> can return false. > > > > >> [1] > >http://quotesnack.com/ralph-waldo-emerson/a-foolish-consistency-is-th... > > > >> ;-) > > > > >> In the meantime, I've managed to convince myself that I understand how > > > >> createGetter() works, so, yea, it probably wouldn't be very difficult > > > >> to implement my withX(x) builders for immutable types. Supporting a > > > >> variant of @Data and @Setter to provide the OP's chainable setX > > > >> methods would probably be even simpler. > > > > >> Yea, Lombok's a nice bit of work. > > > > >> // Ben > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups "The Java Posse" group. > > > > To post to this group, send email to [email protected]. > > > > To unsubscribe from this group, send email to > > [email protected]<javaposse%2bunsubscr...@googlegroups > > .com> > > . > > > > For more options, visit this group athttp:// > > groups.google.com/group/javaposse?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<javaposse%2bunsubscr...@googlegroups > > .com> > > . > > For more options, visit this group at > >http://groups.google.com/group/javaposse?hl=en. > > -- > Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
