A conditional +1; can I simply edit and save code without "benefit" of a formatter? That could probably be via an installable "formatter" that does _nothing_ to my code. Given that option, I'm all in favor of what makes others happy.
Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Adrian Lienhard Sent: Thursday, March 04, 2010 2:49 PM To: Pharo Development Subject: Re: [Pharo-project] about code formatting in pharo +1 On Mar 4, 2010, at 19:10 , Dale Henrichs wrote: > It is obvious that a consensus will not be reached on the "one and only true > format." > > If my browser displays code formatted the way I want to see it and the > difference tools are format neutral (i.e., the source and target code is > formatted using the same rules) there is no need to agree on a standard > style. For all intents and purposes each developer's favored format _is the > standard_. > > We only need to agree to disagree and then figure out how to make it possible > to customize the formatter and resolve any other technical details > (performance and others) that are deemed important. These are technical > problems with technical solutions. > > Dale > ----- "Chris Muller" <[email protected]> wrote: > > | > Another visual problem with "[" and "]" is that they are but one > | > character, and if you place them together with something else, > | > like "[self", they lose their visual identity (btw, we read words > | > in > | chunks > | > not by characters) and get harder to spot. It's true that some > | > fonts and extra coloring could solve this problem, but whitespace > | > is > | always > | > the best and least invasive design weapon. > | > | Tudor, for what its worth, the white-space surrounding the blocks is > | not really at issue or discussion here. It's about formatting > | blocked code into rectangular shapes. > | > | In fact, I agree with you about your point about the whitespace. > | IOW, I prefer: > | > | someVar = someValue > | ifTrue: [ self doOneThing ] > | ifFalse: > | [ self > | doOtherThing ; > | doYetAnotherThing. > | anotherObject doSomething ] > | > | Not: > | > | someVar = someValue > | ifTrue: [self doOneThing] > | ifFalse: > | [self > | doOtherThing ; > | doYetAnotherThing. > | anotherObject doSomething] > | > | Perhaps if you looked at a longer method example, with nested > | blocks, you might be able to "see", visually, the blocks more obviously. > | Perhaps not, I don't know. > | > | Regards, > | Chris > | > | > The lines are clearly belonging together, [ is clearly observed > | > and clicking anywhere on the first line after [ will select the > | > whole > | block. > | > > | > Yet another thing it solves is the consistency between block and > | > method. They both define behavior, and thus it would be great if > | they > | > would be treated similarly. This is better seen in the context of > | > a block with parameter: > | > > | > aCollection do: [ :each | > | > self something. > | > self somethingElse. ] > | > > | > Just like a method has the top line with the signature and the > | > parameters, a block should be the same. In this case, each is a > | > parameter and it is clearly distinct from everything else. When > | there > | > is no parameter, this is information made very clear, too (because > | of > | > the absence of anything following [ ). > | > > | > > | > An argument against this convention was that it looks like C and > | that > | > blocks are not dumb {. While I understand the built-in adversity, > | > we are talking about a visual notation that makes sense for > | > Smalltalk > | and > | > not one that make it different from everything else around us. > | > > | > Another option would be to have: > | > boolean ifTrue: > | > [ self clearCaches. > | > self current soleInstance yada yada blah blah > | > self recomputeAngle ] > | > > | > with everything inside the block being aligned. However, this has > | the > | > problem of wasting space. One space can also be used, but only > | > when the font is monospaced, so it would not work in general. > | Furthermore, > | > it would be inconsistent or even more space wasting when it comes > | > to blocks with parameters. > | > > | > Cheers, > | > Doru > | > > | > > | > On 4 Mar 2010, at 03:38, Chris Muller wrote: > | > > | >>>> ifTrue: [ > | >>>> line1 yo. > | >>>> line2 eh ] > | >>> > | >>> Horrible, horrible, horrible ;) Poor block. The block is an > | >>> object... > | >> > | >> Exactly what I was thinking; and how some of the new editor > | features > | >> since 3.9, that seem to reify "statements". For example, > | >> clicking inside parens or square-brackets selects that > | >> statement(s). I also really enjoyed the ability to "surround", > | >> thereby creating > | additional > | >> statement-levels. > | >> > | >> The whole interaction becomes much more liked working with tiled > | code > | >> rather than a text-editor. > | >> > | >>> 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. > | >> > | >> As someone who's logged 5-digits of hours in Squeak these last > | >> few years, I think the best thing is to just not. Let 'em wrap! > | >> Use shout to turn them light gray, so they don't really intrude > | >> on the code, but are there if you want focus on the extra prose. > | >> > | >> Unfortunately, the real problem with comments within BlockNodes > | >> is > | how > | >> they duplicate themselves within the parse-tree.. ouch! I hope > | that > | >> is what you and Nicolas were talking about or that you'll have a > | fix > | >> for that.. > | >> > | >>> 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. > | >> > | >> Very cool, I hope there'll be enough additional consensus to > | >> adopt these Beckian formats for Squeaks pretty-print refinement. > | >> > | >>> 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 :) > | >> > | >> Absolutely. To not, would be the machine dictating to the user. > | >> Invoking automatic formatting is always the users choice. > | >> browseWithPrettyPrint allows readers to have it formatted > | dynamically > | >> if they wish.. > | >> > | >> Cheers.. > | >> > | >>> P.S. and don't get me started on the trailing period (putrid > | >>> excressence), or the space between ^ and the return expression > | >>> (vomitous mass). > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> [email protected] > | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proje > | >> ct > | > > | > -- > | > www.tudorgirba.com > | > > | > "Live like you mean it." > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > [email protected] > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-projec > | > t > | > > | > | _______________________________________________ > | 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 _______________________________________________ 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
