[squeak-dev] Coding style

Levente Uzonyi leves at elte.hu
Wed Mar 10 17:42:08 UTC 2010


On Wed, 10 Mar 2010, Eliot Miranda wrote:

> On Wed, Mar 10, 2010 at 4:47 AM, Levente Uzonyi <leves at elte.hu> wrote:
>
>> On Wed, 10 Mar 2010, Bert Freudenberg wrote:
>>
>>  On 10.03.2010, at 02:53, commits at source.squeak.org 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 ...)
>>>
>>
>>
>>>
>>>
>>>
>>
>



More information about the Squeak-dev mailing list