Then have you also noticed, that newspaper articles are among the hardest to read for kids learning?
We're all different, but I find the opposite from you applies to myself. My brain wants to scan and break source up into chunks of isolated semantic. To that effect, I also tend to write one liners when I can - I have no need to expose temporary mutable variables into the scope. Source code should be about the smoothest transfer of an AST (the compiler doesn't care how it's fed this) into my brain. Having to parse statement with multiple double-nests, is counter-productive to this goal. Java is not exactly the most succinct language and monitors are dirt cheap. We could go a long way with a smart IDE handling line-wrapping, something hopefully we shall have in NetBeans 7. On Oct 13, 10:54 pm, Mark Volkmann <[email protected]> wrote: > 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 > > athttp://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.
