On Wed, Mar 3, 2010 at 1:50 PM, Yanni Chiu <[email protected]> wrote: > Chris Muller wrote: > > On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu <[email protected]> wrote: > >> Isn't readability a matter of taste...? > > > > Not according to the pattern description; did you read it? It says, > > the "tendency of the eye to distinguish and interpolate vertical and > > horizontal lines. The square brackets used to signify blocks lead the > > eye to create the illusion of a whole rectangle even though one isn't > > there." For me, it's absolutely true. > > I was going from memory of Beck'isms, but I've read it just now. Now I > remember that I didn't like this rule the last time I read it. I still > think it's handwaving, without studies done with Smalltalk code, but > let's go along with the argument for now: the eye can distinguish > rectangles easily, so to have better readability, arrange '[' and ']' to > create a rectangular illusion. >
I assure you that for a good many of us (me included) it works very well. > > In the first example: > > ifTrue: [self recomputeAngle] > > I see a rectangle formed by the '[' and ']' on the same line. So, I buy > the argument. > > In the second example given: > > ifTrue: > [self clearCaches. > self recomputeAngle] > > The rectangle is getting harder for me to spot, and the argument is > starting to feel sketchy to me. > > What happens with more lines: > > ifTrue: > [self clearCaches. > self current soleInstance yada yada blah blah > self recomputeAngle] > Where's the rectangle now? Compare this with the highly disturbing fact > (to me, anyways) that the first line should have the same level of > indent as the rest of the lines in the block, but it's tabbed differently. > I see it immediately and it looks elegant and comprehensible. It doesn't for you. We're all wired differently. I suspect that if you're a visual thinker Beck's rule is for you, and if you're not you'll hate it. > > > I'm not sure what "hanging left bracket" is. In Rectangular Block, > > subsequent lines have the "same tabbing" so it may be the same thing. > > I just made up the term because some other poster had mentioned they'd > never seen code where the '[' was left dangling at the end of a line. I > should have give an example: > > ifTrue: [ > line1 yo. > line2 eh ] > Horrible, horrible, horrible ;) Poor block. The block is an object, not braces in some pathetic C derivative. It needs love and respect. Its beginning doesn't belong to the ifTrue:, its entirety is an argument to ifTrue:. The rectangular rule emphasises this (for those that can see it ;) ). > > > I don't know how anything related to formatting could be faster than > > having the machine doing it. > > When the automated formatting does a poor job, and you have do undo it > manually. Or, you refactor your code just so the automated formatting > does a good job. > > > But if you are not using > > automatic-formatting, then you won't really be affected by these > > proposed pretty-print changes.. > > This thread started out talking about how the core Pharo code base > should be formatted. Maybe the Squeak thread was only about > pretty-printing. > I think the conclusion has to be (and I can confirm that the VisualWorks team was equally divided) that no one formatting regime will make every one happy and that all regimes will make a substantial minority unhappy. So perhaps we should step up to having code formatted automatically according to tailorable preferences. My only concern is comment formatting but the way to deal with that is to use automatic formatting and deal with comment problems as they arise. I always used to be concerned about e.g. comments spanning multiple lines. But without day to day exposure I don't think one can know how much of an issue it is. One upside will be less effort reformatting when indent levels change. Have you noticed that Smalltalk tends to be more difficult to reformat than C syntax languages, I guess because of keywords? Not having to worry about this could be great. Of course, what format gets written to a source file could still be a source of conflict ;) We may all want our syntax to be the format of record :) best Eliot P.S. and don't get me started on the trailing period (putrid excressence), or the space between ^ and the return expression (vomitous mass). > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
