I always wondered why printing newspaper articles in narrow columns aids readability, but many software developers prefer going past 80 characters (which is already far wider than newspaper columns). Personally I find code that stays within 80 characters easier to scan with my eyes. Also, it has the side benefit that if I decide to print the code, it fits without wrapping.
On Wed, Oct 13, 2010 at 3: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]. >> > 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]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- R. Mark Volkmann Object Computing, Inc. -- 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.
