130 or so characters fits into the 7" display on my Asus EEE, without choosing a small font deliberately.
I don't mind small lines, but I enforce a 'no arbitrary breaking' rule on the projects I lead. This means that you should ideally never break lines, but instead alter something about them (introduce an explaining variable, perhaps) to make sure that the line lengths stay reasonable. I don't define reasonable, that will just vary naturally as people have larger or smaller displays. I haven't really had a problem with this in reading diffs, but I can imagine that being tricky in more heavily nested code. 2010/10/13 Cédric Beust ♔ <[email protected]>: > 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]. >> > > 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. >> > > > > -- > 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. > -- 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.
