Coding style
Locked
 
|
On 10.03.2010, at 02:53, [hidden email] wrote:
> > + ^packageList ifNil:[packageList := (PackageInfo allPackages collect: [ :each | each packageName]) sort]! > - ^packageList ifNil:[packageList := (MCWorkingCopy allManagers collect:[:each| each packageName]) sort]! This to me replaces one style of too few spaces with another of too many ;) I'd have written collect: [:each | each packageName] but I just looked at the Blue Book and there indeed is a space before and after a block argument. OTOH it does conform to Kent's examples: http://c2.com/ppr/formatting.html Generally I feel this is not much of a problem. But I have occasionally seen rather strange formatting, So for the benefit of better readability, do we want to have general rules for formatting code? Many projects have such rules. One good example IMHO is PEP-8 in the Python community. For Smalltalk I only know Kent Beck's rules from "Best Practice Patterns" which seem like a good set. And IMHO any rules are better than none, so maybe we want to just agree that if in doubt, follow that suggested practice? - Bert - (hoping this does not open a can of worms ...) |
|
|
2010/3/10 Bert Freudenberg <[hidden email]>:
> On 10.03.2010, at 02:53, [hidden email] wrote: >> >> + ^packageList ifNil:[packageList := (PackageInfo allPackages collect: [ :each | each packageName]) sort]! >> - ^packageList ifNil:[packageList := (MCWorkingCopy allManagers collect:[:each| each packageName]) sort]! > > > This to me replaces one style of too few spaces with another of too many ;) > > I'd have written > > collect: [:each | each packageName] > > but I just looked at the Blue Book and there indeed is a space before and after a block argument. OTOH it does conform to Kent's examples: > > http://c2.com/ppr/formatting.html > > Generally I feel this is not much of a problem. But I have occasionally seen rather strange formatting, So for the benefit of better readability, do we want to have general rules for formatting code? > > Many projects have such rules. One good example IMHO is PEP-8 in the Python community. > > For Smalltalk I only know Kent Beck's rules from "Best Practice Patterns" which seem like a good set. And IMHO any rules are better than none, so maybe we want to just agree that if in doubt, follow that suggested practice? > > - Bert - (hoping this does not open a can of worms ...) > Same discussion was just taking place at Pharo a few days ago. There seem to be established rules also for Seaside & co package developpers. Nicolas |
|
|
On 10.03.2010, at 11:29, Nicolas Cellier wrote:
> > 2010/3/10 Bert Freudenberg <[hidden email]>: >> On 10.03.2010, at 02:53, [hidden email] wrote: >>> >>> + ^packageList ifNil:[packageList := (PackageInfo allPackages collect: [ :each | each packageName]) sort]! >>> - ^packageList ifNil:[packageList := (MCWorkingCopy allManagers collect:[:each| each packageName]) sort]! >> >> >> This to me replaces one style of too few spaces with another of too many ;) >> >> I'd have written >> >> collect: [:each | each packageName] >> >> but I just looked at the Blue Book and there indeed is a space before and after a block argument. OTOH it does conform to Kent's examples: >> >> http://c2.com/ppr/formatting.html >> >> Generally I feel this is not much of a problem. But I have occasionally seen rather strange formatting, So for the benefit of better readability, do we want to have general rules for formatting code? >> >> Many projects have such rules. One good example IMHO is PEP-8 in the Python community. >> >> For Smalltalk I only know Kent Beck's rules from "Best Practice Patterns" which seem like a good set. And IMHO any rules are better than none, so maybe we want to just agree that if in doubt, follow that suggested practice? >> >> - Bert - (hoping this does not open a can of worms ...) >> > > Same discussion was just taking place at Pharo a few days ago. > There seem to be established rules also for Seaside & co package developpers. > > Nicolas Ah, can you point us to those rules? Simplest might be to just adopt them for trunk packages. - Bert - |
|
|
In reply to this post by Bert Freudenberg
On Wed, 10 Mar 2010, Bert Freudenberg wrote:
> On 10.03.2010, at 02:53, [hidden email] wrote: >> >> + ^packageList ifNil:[packageList := (PackageInfo allPackages collect: [ :each | each packageName]) sort]! >> - ^packageList ifNil:[packageList := (MCWorkingCopy allManagers collect:[:each| each packageName]) sort]! > > > This to me replaces one style of too few spaces with another of too many ;) > > I'd have written > > collect: [:each | each packageName] > > but I just looked at the Blue Book and there indeed is a space before and after a block argument. OTOH it does conform to Kent's examples: > > http://c2.com/ppr/formatting.html > I try not to change the formatting of methods written by others to my taste, but there are times when I just can't stop myself. This one liner is half baked though... If this was written by me entirely it would look like something like this: ^packageList ifNil: [ packageList := (PackageInfo allPackages collect: [ :each | each packageName ]) sort ] I used to add a space before and after all [ and ]. > Generally I feel this is not much of a problem. But I have occasionally seen rather strange formatting, So for the benefit of better readability, do we want to have general rules for formatting code? > > Many projects have such rules. One good example IMHO is PEP-8 in the Python community. > > For Smalltalk I only know Kent Beck's rules from "Best Practice Patterns" which seem like a good set. And IMHO any rules are better than none, so maybe we want to just agree that if in doubt, follow that suggested practice? > If someone has his/her own code formatting rules, he/she will hardly change to another. I find my rules (which are mostly based on this book: http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf ) very readable, especially with shout which colorizes the brackets too. Therefore I'm against of forcing a single code formatting. I personally dislike Kent's "rectangular block" idea. For example: I found this more readable aCollection do: [ :each | stream nextPut: $(; print: each; nextPut: $) ] separatedBy: [ stream nextPut: $,; space ] than this aCollection do: [:each | stream nextPut: $(; print: each; nextPut: $)] separatedBy: [stream nextPut: $,; space] You can notice the rectangular shape in both examples. I think the best would be a highly customizable pretty printer which would allow anyone to read all methods formatted in the way he/she prefers. Levente > - Bert - (hoping this does not open a can of worms ...) > > > |
|
|
On Wed, Mar 10, 2010 at 4:47 AM, Levente Uzonyi <[hidden email]> wrote:
But with Kent's approach a block's contents lie within its rectangular area. With your first example only "Put: $(;" and "ce" lie within the block and that breaks the appearance of a rectangular block, being more like a potato sack bulging at the side ;) and is inelegant, ugly, etc, etc. So...
I think the best would be a highly customizable pretty printer which would allow anyone to read all methods formatted in the way he/she prefers. +1
|
|
|
In reply to this post by Bert Freudenberg
2010/3/10 Bert Freudenberg <[hidden email]>:
> On 10.03.2010, at 11:29, Nicolas Cellier wrote: >> >> 2010/3/10 Bert Freudenberg <[hidden email]>: >>> On 10.03.2010, at 02:53, [hidden email] wrote: >>>> >>>> + ^packageList ifNil:[packageList := (PackageInfo allPackages collect: [ :each | each packageName]) sort]! >>>> - ^packageList ifNil:[packageList := (MCWorkingCopy allManagers collect:[:each| each packageName]) sort]! >>> >>> >>> This to me replaces one style of too few spaces with another of too many ;) >>> >>> I'd have written >>> >>> collect: [:each | each packageName] >>> >>> but I just looked at the Blue Book and there indeed is a space before and after a block argument. OTOH it does conform to Kent's examples: >>> >>> http://c2.com/ppr/formatting.html >>> >>> Generally I feel this is not much of a problem. But I have occasionally seen rather strange formatting, So for the benefit of better readability, do we want to have general rules for formatting code? >>> >>> Many projects have such rules. One good example IMHO is PEP-8 in the Python community. >>> >>> For Smalltalk I only know Kent Beck's rules from "Best Practice Patterns" which seem like a good set. And IMHO any rules are better than none, so maybe we want to just agree that if in doubt, follow that suggested practice? >>> >>> - Bert - (hoping this does not open a can of worms ...) >>> >> >> Same discussion was just taking place at Pharo a few days ago. >> There seem to be established rules also for Seaside & co package developpers. >> >> Nicolas > > Ah, can you point us to those rules? Simplest might be to just adopt them for trunk packages. > > > - Bert - > We should ask Lukas probably, or just use the code formatter from RB? Nicolas |
|
|
In reply to this post by Eliot Miranda-2
On Wed, 10 Mar 2010, Eliot Miranda wrote:
> On Wed, Mar 10, 2010 at 4:47 AM, Levente Uzonyi <[hidden email]> wrote: > >> On Wed, 10 Mar 2010, Bert Freudenberg wrote: >> >> On 10.03.2010, at 02:53, [hidden email] wrote: >>> >>>> >>>> + ^packageList ifNil:[packageList := (PackageInfo allPackages >>>> collect: [ :each | each packageName]) sort]! >>>> - ^packageList ifNil:[packageList := (MCWorkingCopy allManagers >>>> collect:[:each| each packageName]) sort]! >>>> >>> >>> >>> This to me replaces one style of too few spaces with another of too many >>> ;) >>> >>> I'd have written >>> >>> collect: [:each | each packageName] >>> >>> but I just looked at the Blue Book and there indeed is a space before and >>> after a block argument. OTOH it does conform to Kent's examples: >>> >>> http://c2.com/ppr/formatting.html >>> >>> >> I try not to change the formatting of methods written by others to my >> taste, but there are times when I just can't stop myself. This one liner is >> half baked though... >> If this was written by me entirely it would look like something like this: >> >> >> ^packageList ifNil: [ >> packageList := (PackageInfo allPackages collect: [ :each | >> each packageName ]) sort ] >> >> I used to add a space before and after all [ and ]. >> >> >> Generally I feel this is not much of a problem. But I have occasionally >>> seen rather strange formatting, So for the benefit of better readability, do >>> we want to have general rules for formatting code? >>> >>> Many projects have such rules. One good example IMHO is PEP-8 in the >>> Python community. >>> >>> For Smalltalk I only know Kent Beck's rules from "Best Practice Patterns" >>> which seem like a good set. And IMHO any rules are better than none, so >>> maybe we want to just agree that if in doubt, follow that suggested >>> practice? >>> >>> >> If someone has his/her own code formatting rules, he/she will hardly change >> to another. I find my rules (which are mostly based on this book: >> http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf) very readable, especially with shout which colorizes the brackets too. >> >> Therefore I'm against of forcing a single code formatting. I personally >> dislike Kent's "rectangular block" idea. >> For example: >> I found this more readable >> >> aCollection >> do: [ :each | >> stream >> nextPut: $(; >> print: each; >> nextPut: $) ] >> separatedBy: [ >> stream >> nextPut: $,; >> space ] >> >> than this >> >> aCollection >> do: >> [:each | >> stream >> nextPut: $(; >> print: each; >> nextPut: $)] >> separatedBy: >> [stream >> nextPut: $,; >> space] >> >> You can notice the rectangular shape in both examples. >> > > But with Kent's approach a block's contents lie within its rectangular area. > With your first example only "Put: $(;" and "ce" lie within the block and > that breaks the appearance of a rectangular block, being more like a potato > sack bulging at the side ;) and is inelegant, ugly, etc, etc. So... It depends on your font, tab size, etc. On my screen the second block's rectangle doesn't contain "t: $,;" with Kent's approach, so it's not a rectangle at all. And with "my" approach the rectangle is not defined by [ and ], but by stream and ]. Also loops are unreadable with Kent's approach: [[x := z + 1. y = x] whileTrue. ^y] value No rectangles here... Levente > > > I think the best would be a highly customizable pretty printer which would >> allow anyone to read all methods formatted in the way he/she prefers. >> > > +1 > > >> >> >> Levente >> >> >> - Bert - (hoping this does not open a can of worms ...) >>> >> >> >>> >>> >>> >> > |
|
|
In reply to this post by Nicolas Cellier
How can we use that? Does RefactoringBrowser load into trunk image now?
On Wed, Mar 10, 2010 at 11:15 AM, Nicolas Cellier <[hidden email]> wrote: > 2010/3/10 Bert Freudenberg <[hidden email]>: >> On 10.03.2010, at 11:29, Nicolas Cellier wrote: >>> >>> 2010/3/10 Bert Freudenberg <[hidden email]>: >>>> On 10.03.2010, at 02:53, [hidden email] wrote: >>>>> >>>>> + ^packageList ifNil:[packageList := (PackageInfo allPackages collect: [ :each | each packageName]) sort]! >>>>> - ^packageList ifNil:[packageList := (MCWorkingCopy allManagers collect:[:each| each packageName]) sort]! >>>> >>>> >>>> This to me replaces one style of too few spaces with another of too many ;) >>>> >>>> I'd have written >>>> >>>> collect: [:each | each packageName] >>>> >>>> but I just looked at the Blue Book and there indeed is a space before and after a block argument. OTOH it does conform to Kent's examples: >>>> >>>> http://c2.com/ppr/formatting.html >>>> >>>> Generally I feel this is not much of a problem. But I have occasionally seen rather strange formatting, So for the benefit of better readability, do we want to have general rules for formatting code? >>>> >>>> Many projects have such rules. One good example IMHO is PEP-8 in the Python community. >>>> >>>> For Smalltalk I only know Kent Beck's rules from "Best Practice Patterns" which seem like a good set. And IMHO any rules are better than none, so maybe we want to just agree that if in doubt, follow that suggested practice? >>>> >>>> - Bert - (hoping this does not open a can of worms ...) >>>> >>> >>> Same discussion was just taking place at Pharo a few days ago. >>> There seem to be established rules also for Seaside & co package developpers. >>> >>> Nicolas >> >> Ah, can you point us to those rules? Simplest might be to just adopt them for trunk packages. >> >> >> - Bert - >> > > We should ask Lukas probably, or just use the code formatter from RB? > > Nicolas > > |
|
|
In reply to this post by Bert Freudenberg
Here are some other factors to consider about formatting.
- I have proposed Compiler packages which format to a Rectangular Block style. They are in the inbox, we can use this for discussion and collaboration. - I like to have some *reason* for our formatting. Kent Beck's "best-practice" offers legitimate arguments for the formatting choice over personal style. - The current pretty-print style is unnattractive, hard to read and, worst, not very functional. - By "not very functional" I mean: 1) Without adequate spacing, it is harder to select "statements" by clicking just inside Block arguments. 2) When there is no space after a block argument, as in, :each, then double-clicking on it for cut-and-paste purposes requires a fine motor drag rather than a (gross-motor) double click. It also seems inconsistent with method-arguments, which place a space between the colon and the argument name. 3) Our differ is line-based. With the current format, diffing puts too much text on one-line, causing the human to incur, again, work that should be done by the computer. If we cannot agree on a final "best" form, perhaps we can agree, for the sake of productivity, to something that has relatively more "function" according to the above problems. I made updates to the work I've done to account for Eliot's and Juan's taste over my own. The three of us all like Rectangular Block. I think we should adopt this into trunk for purely the funtional producitivity reasons stated, and then someone who hates Rectangular Block enough should do the work to write something that allows that to be a formatting preference. Obviously, no one solution can make everyone happy. But what's in the "inbox" is an improvement for the tangible reasons described above, and for tangible reasons published in a book. I ask if we can move forward, one incremental step, and still leave this issue open for discussion on the table for further improvement. - Chris On Wed, Mar 10, 2010 at 4:25 AM, Bert Freudenberg <[hidden email]> wrote: > On 10.03.2010, at 02:53, [hidden email] wrote: >> >> + ^packageList ifNil:[packageList := (PackageInfo allPackages collect: [ :each | each packageName]) sort]! >> - ^packageList ifNil:[packageList := (MCWorkingCopy allManagers collect:[:each| each packageName]) sort]! > > > This to me replaces one style of too few spaces with another of too many ;) > > I'd have written > > collect: [:each | each packageName] > > but I just looked at the Blue Book and there indeed is a space before and after a block argument. OTOH it does conform to Kent's examples: > > http://c2.com/ppr/formatting.html > > Generally I feel this is not much of a problem. But I have occasionally seen rather strange formatting, So for the benefit of better readability, do we want to have general rules for formatting code? > > Many projects have such rules. One good example IMHO is PEP-8 in the Python community. > > For Smalltalk I only know Kent Beck's rules from "Best Practice Patterns" which seem like a good set. And IMHO any rules are better than none, so maybe we want to just agree that if in doubt, follow that suggested practice? > > - Bert - (hoping this does not open a can of worms ...) > > > |
|
|
In reply to this post by Levente Uzonyi-2
> aCollection
Just for discussion, this is how the pretty-printer proposed in the
> do: [ :each | > stream > nextPut: $(; > print: each; > nextPut: $) ] > separatedBy: [ > stream > nextPut: $,; > space ] > > You can notice the rectangular shape in both examples. inbox formats this: aCollection do: [ : each | stream nextPut: $( ; print: each ; nextPut: $) ] separatedBy: [ stream nextPut: $, ; space ] So it seems the main difference is that Levente prefers blocks to start on the same rather than next line. That could probably be made a preference.. |
|
|
On 3/10/2010 1:30 PM, Chris Muller wrote:
> So it seems the main difference is that Levente prefers blocks to > start on the same rather than next line. That could probably be made > a preference.. FWIW, I think pretty-printing should be implemented by a simple visitor so that people can trivially write their own rules. It's fair to have a few preferences but I don't think a one-size-fits-all approach can possibly work when it comes to style. Cheers, - Andreas |
|
|
2010/3/10 Andreas Raab <[hidden email]>:
> On 3/10/2010 1:30 PM, Chris Muller wrote: >> >> So it seems the main difference is that Levente prefers blocks to >> start on the same rather than next line. That could probably be made >> a preference.. > > FWIW, I think pretty-printing should be implemented by a simple visitor so > that people can trivially write their own rules. It's fair to have a few > preferences but I don't think a one-size-fits-all approach can possibly work > when it comes to style. > > Cheers, > - Andreas > Among things I dont like: source: test ^16r7F pretty print: test ^127 |
|
|
On Wed, Mar 10, 2010 at 1:44 PM, Nicolas Cellier <[hidden email]> wrote: 2010/3/10 Andreas Raab <[hidden email]>: +1. But you're going to have to attach metadata to e.g. LiteralNode and get that metadata from the number parsing. And for fixing that, You Da Man!! :) :) |
|
|
On 10.03.2010, at 22:47, Eliot Miranda wrote:
What would be Way Cool is if the "source code" would just be some hints to reformat the decompiler output to match what was typed. There could be immense space savings :) Though my original question wasn't at all about pretty printing but I guess that direction of discussion was to be expected ... - Bert - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |