Coding style

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Coding style

Bert Freudenberg
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 ...)


Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Nicolas Cellier
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

Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Bert Freudenberg
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 -



Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Levente Uzonyi-2
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 ...)

>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Eliot Miranda-2


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...


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 ...)








Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Nicolas Cellier
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

Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Levente Uzonyi-2
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 ...)
>>>
>>
>>
>>>
>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Chris Muller-3
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Chris Muller-3
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 ...)
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Chris Muller-3
In reply to this post by Levente Uzonyi-2
> aCollection

>        do: [ :each |
>                stream
>                        nextPut: $(;
>                        print: each;
>                        nextPut: $) ]
>        separatedBy: [
>                stream
>                        nextPut: $,;
>                        space ]
>
> You can notice the rectangular shape in both examples.
Just for discussion, this is how the pretty-printer proposed in the
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..


Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Andreas.Raab
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


Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Nicolas Cellier
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

Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Eliot Miranda-2


On Wed, Mar 10, 2010 at 1:44 PM, Nicolas Cellier <[hidden email]> wrote:
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


+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!! :) :)



Reply | Threaded
Open this post in threaded view
|

Re: Coding style

Bert Freudenberg
On 10.03.2010, at 22:47, Eliot Miranda wrote:


On Wed, Mar 10, 2010 at 1:44 PM, Nicolas Cellier <[hidden email]> wrote:
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


+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!! :) :)

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 -