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%[email protected]> > . > > > 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%[email protected]> > . > 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.
