Re: [Pharo-project] about code formatting in pharo
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" <asqueaker@gmail.com> 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 | >> Pharo-project@lists.gforge.inria.fr | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > -- | > www.tudorgirba.com | > | > "Live like you mean it." | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes for tool support even if I would like to have the code of the core to be nicely and consistently formatted. Since I learned smalltalk with VW I like
someVar = someValue | ifTrue: [self doOneThing] | ifFalse: | [self | doOtherThing ; | doYetAnotherThing. | anotherObject doSomething]
:) But I can understand that other prefer the ifTrue: [ self doOtherThing ; doYetAnotherThing. anotherObject doSomething] On Mar 4, 2010, at 7:10 PM, 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" <asqueaker@gmail.com> 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 | >> Pharo-project@lists.gforge.inria.fr | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > -- | > www.tudorgirba.com | > | > "Live like you mean it." | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+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" <asqueaker@gmail.com> 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 | >> Pharo-project@lists.gforge.inria.fr | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > -- | > www.tudorgirba.com | > | > "Live like you mean it." | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] 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" <asqueaker@gmail.com> 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 | >> Pharo-project@lists.gforge.inria.fr | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proje | >> ct | > | > -- | > www.tudorgirba.com | > | > "Live like you mean it." | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-projec | > t | > | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
Of course. I think most agree that the machine doesn't dictate anything to the user. The related preferences are: browseWithPrettyPrint, diffsWithPrettyPrint. If you want to actually alter saved format, you must pretty-print the method and save it. I also agree with Dale others who voiced the sentiment that probably not enough consensus can be reached to avoid the work of needing to make a SmalltalkFormatter or SmalltalkPrinter class of some kind. Sigh.. :) So how does that sound? Just dispatching portions of the various "printing" methods in subclasses of ParseNode to a Printer that allows individual preferences to be specified? I don't see anything too grand or fancy being necessary to gain quite a productivity boost out of all of us if we can have the machine format to our liking. Not too fancy will probably work, verbatim, in both the Pharo and Squeak images.. On Thu, Mar 4, 2010 at 2:40 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] 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" <asqueaker@gmail.com> 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 | >> Pharo-project@lists.gforge.inria.fr | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proje | >> ct | > | > -- | > www.tudorgirba.com | > | > "Live like you mean it." | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-projec | > t | > | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
So how does that sound? Â Just dispatching portions of the various "printing" methods in subclasses of ParseNode to a Printer that allows individual preferences to be specified?
This thing is called RBConfigurableFormatter and it has been present for the last decade. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Cool, "present" is a start. But how do I use it? In Pharo 10508, I executed: RBConfigurableFormatter stringFollowingReturn: '' "<--- String empty" and then tried the "format" option in a method that has "^ something", but it did not remove the extra space. In fact, I'm not sure it even tried to format anything; I didn't have time to debug it. In any case, if Pharo is using RB for formatting then separate solutions for Squeak and Pharo may be necessary after-all.. :( On Thu, Mar 4, 2010 at 3:18 PM, Lukas Renggli <renggli@gmail.com> wrote:
So how does that sound? Â Just dispatching portions of the various "printing" methods in subclasses of ParseNode to a Printer that allows individual preferences to be specified?
This thing is called RBConfigurableFormatter and it has been present for the last decade.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
and then tried the "format" option in a method that has "^ something", but it did not remove the extra space. Â In fact, I'm not sure it even tried to format anything; I didn't have time to debug it. Â In any case, if Pharo is using RB for formatting then separate solutions for Squeak and Pharo may be necessary after-all.. Â :(
If you use PharoDev it should be used. In PharoCore RB is not loaded. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
participants (6)
-
Adrian Lienhard -
Chris Muller -
Dale Henrichs -
Lukas Renggli -
Schwab,Wilhelm K -
Stéphane Ducasse