Smalltalk › Squeak › Squeak - Dev

Formatting? was: Re: [squeak-dev] The Trunk: ToolBuilder-Morphic-cmm.164.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Eliot Miranda-2

Re: Formatting?

On Thu, Jun 2, 2016 at 9:25 AM, tim Rowledge <[hidden email]> wrote:

{snipping lots}
> On 02-06-2016, at 8:19 AM, Levente Uzonyi <[hidden email]> wrote:
>
>>
>> braceAtTheEndOfLine ifTrue: [
>> (this isA: #Monstrosity) because:
>> blocks are objects not syntax].
>
> This is absolutely personal preference, but I prefer to have blocks have
> similar syntax as methods, because that makes it easier to read code.
> This means that the first line, which contains the opening bracket and the argument names, is far less important than what the block does, so it's perfectly okay to leave it on the previous line.

So I think you mean
coll do: [:each|
statement.
argument.
resolution].
… which is pretty much how I prefer things.

No. That puts the start of the block to the right of the first line of the block. That's not rectangular at all. i.e. "statement" is to the left of "[:each|". It should be

coll do:

[:each|
statement.
argument.
resolution].

Here, all the text of the block is included in the recangle formed by "[:each|" and "resolution]".

We should be very careful about discussing this. I don’t think anything causes more annoyance, hard feeling, lost friendships, broken communities, lost projects and global war than syntactic debates.

Understood. Bt Kent gives v good rationale for all elements of his style guide, and one way of avoiding conflicts over formatting is to have and observe as much as possible, and support with tools, a house style.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IO: Illogical Or

_,,,^..^,,,_

best, Eliot

Levente Uzonyi

Re: Formatting?

On Thu, 2 Jun 2016, Eliot Miranda wrote:

>
>
> On Thu, Jun 2, 2016 at 9:25 AM, tim Rowledge <[hidden email]> wrote:
> {snipping lots}
> > On 02-06-2016, at 8:19 AM, Levente Uzonyi <[hidden email]> wrote:
> >
> >>
> >> braceAtTheEndOfLine ifTrue: [
> >> (this isA: #Monstrosity) because:
> >> blocks are objects not syntax].
> >
> > This is absolutely personal preference, but I prefer to have blocks have
> > similar syntax as methods, because that makes it easier to read code.
> > This means that the first line, which contains the opening bracket and the argument names, is far less important than what the block does, so it's perfectly okay to leave it on the previous
> line.
>
> So I think you mean
> coll do: [:each|
> statement.
> argument.
> resolution].
> … which is pretty much how I prefer things.
>
>
> No. That puts the start of the block to the right of the first line of the block. That's not rectangular at all. i.e. "statement" is to the left of "[:each|". It should be

IMHO it's enough for easy pattern recognition if the statements form a
rectangle.

Levente

>
> coll do:
> [:each|
> statement.
> argument.
> resolution].
>
> Here, all the text of the block is included in the recangle formed by "[:each|" and "resolution]".
>
>
> We should be very careful about discussing this. I don’t think anything causes more annoyance, hard feeling, lost friendships, broken communities, lost projects and global war than syntactic
> debates.
>
>
> Understood. Bt Kent gives v good rationale for all elements of his style guide, and one way of avoiding conflicts over formatting is to have and observe as much as possible, and support with tools, a house
> style.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: IO: Illogical Or
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>

Bert Freudenberg

Re: Formatting?

In reply to this post by Chris Muller-3

On 02.06.2016, at 03:28, Chris Muller <[hidden email]> wrote:

>
>> +1. But having a good formatter which can implement Kent's style guide
>> would be nice. We're not there yet.
>
> Why not give [1] a try? I've tweaked it to remove the spacing which
> you and Bert don't like. Even though I think its a mistake to remove
> this whitespace, we could at least have a pretty-print that is usable
> OOTB and based on a known and thought-out rationale that suits
> Smalltalk. Does anyone know the origins of the formatting we have
> now?
>
> [1] -- Compiler-cmm.323 in the Inbox. I believe its at least 90% Kent
> Beckian, but there are one or two corner-case bugs I couldn't figure
> out how to solve..

It’s pretty good.

There shouldn’t be a space before a cascading semicolon though.

I also noticed a bug where sometimes there is no space between multiple args to a block, e.g. in Behavior>>allSubclassesWithLevelDo:startingLevel:.

And it still produces excessively tall code. This:

classAndLevelBlock
value: self
value: level.

... should be on one line. And if possible

0
to: height - 1
by: 16
do:
[:y | ...

should be

0 to: height - 1 by: 16 do:
[:y | ...

The rule being something like “if only the last arg is complex, put the message on one line, and the last arg indented by one on the next”.

- Bert -

smime.p7s (5K) Download Attachment

Chris Muller-3

Re: Formatting?

> There shouldn’t be a space before a cascading semicolon though.

That one might be easy to fix..

> I also noticed a bug where sometimes there is no space between multiple args to a block, e.g. in Behavior>>allSubclassesWithLevelDo:startingLevel:.
>
> And it still produces excessively tall code. This:
>
> classAndLevelBlock
> value: self
> value: level.
>
> ... should be on one line. And if possible
>
>
> 0
> to: height - 1
> by: 16
> do:
> [:y | ...
>
> should be
>
> 0 to: height - 1 by: 16 do:
> [:y | ...
>
> The rule being something like “if only the last arg is complex, put the message on one line, and the last arg indented by one on the next”.

Right, and also, if the block only has "one statement" in it, should
go on one line, but IIRC "one statement" from POV of a BlockNode (or
whatever it was) could still be a complex multi-line argument
(parenthesis, etc.), so I gave up had it always just does this:

envelopes do:
[ : e | e duration: seconds ]

instead of all on one line. The Command+[Delete] key helps clean that up. :)

So its been a trade-off for me. I find myself still having to do some
manual "clean up" formatting after pretty-printing but, overall, worth
it enough for me that I've been running a dirty Compiler package for
many years..