Code formatting patterns (was: [squeak-dev] The Trunk: Compiler-cmm.275.mcz)

Bert Freudenberg bert at freudenbergs.de
Fri Oct 4 16:23:32 UTC 2013


On 2013-10-04, at 17:45, Chris Muller <asqueaker at gmail.com> wrote:

>>> Compare
>>> 
>>>        [ undeclared at: sym put: nil ]
>>>                on: AttemptToWriteReadOnlyGlobal
>>>                do: [ :noti | noti resume: true ]
>>> 
>>> to:
>>> 
>>>        [ undeclared
>>>                at: sym
>>>                put: nil ]
>>>                on: AttemptToWriteReadOnlyGlobal
>>>                do: [ :noti | noti resume: true ]
>>> 
>>> Isn't the first one much more "rectangular" and easier to read? I find the
>>> indentation in the second one irritating.
> 
> Yes, I agree with you for that one case.  RB, Indented Control Flow,
> etc. do not specify how to handle keywords sent to Blocks.  One
> suggestion is to add a blank line, as in:
> 
>         [ undeclared
>                 at: sym
>                 put: nil ]
> 
>                 on: AttemptToWriteReadOnlyGlobal
>                 do: [ :noti | noti resume: true ]
> 
> Or, an extra indention:
> 
>         [ undeclared
>                 at: sym
>                 put: nil ]
>                      on: AttemptToWriteReadOnlyGlobal
>                      do: [ :noti | noti resume: true ]
> 
> The important thing to handle the _general_ case, so the computer can
> do at least 97% of the formatting.  If we had a larger keyword
> message, your rule would look like this:
> 
>           [ mySoundRecorder copyTo: resultBuf from: j to: (j + n - 1)
> from: buf startingAt: firstInBuf normalize: nFactor dcOffset: dcOffset
> ]
>                   on: AttemptToWriteReadOnlyGlobal
>                   do: [ :noti | noti resume: true ]

You're misinterpreting my "rule" ;)

My rule is more like: If it clearly fits on one line then do not spread it over multiple lines. Otherwise, use your best judgement. :)

For your example I would probably end up with something like

	[ mySoundRecorder
                copyTo: resultBuf from: j to: (j + n - 1)
                from: buf startingAt: firstInBuf
                normalize: nFactor dcOffset: dcOffset
	]
		on: AttemptToWriteReadOnlyGlobal
                do: [ :noti | noti resume: true ]

even if it's not "agile". Source code is read way more often than written, so IMHO it is worth spending some time formatting it to make the meaning as obvious as possible. 

That said, I could live with your version below, in particular if it was automatically produced. It just doesn't feel as nice as the hand-formatted one which even takes into account the semantics of keywords to find suitable breaks.

> which, clearly, is a mess compared to:
> 
>           [ mySoundRecorder
>                 copyTo: resultBuf
>                 from: j
>                 to: (j + n - 1)
>                 from: buf
>                 startingAt: firstInBuf
>                 normalize: nFactor
>                 dcOffset: dcOffset ]
>                      on: AttemptToWriteReadOnlyGlobal
>                      do: [ :noti | noti resume: true ]
> 
> I would LOVE to make pretty print use RB formatting in a way that's
> acceptable to the wider community, so we can be developers and not
> formatting slaves.


- Bert -


More information about the Squeak-dev mailing list