Smalltalk › Squeak › Squeak - Dev

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

49 messages Options

123

Chris Muller-3

Re: Code formatting patterns

>> My gripe with [:each | each doSomething] is that word-selection then includes the colon, which is a pain when you want to Command+h, Command+g it.
>
> Now that sounds like it would be easy to fix, no? We should fix the tools, not work around them.

I happen to like whitespace around variable declarations. Bert your
partisanship is really interesting -- how you declare what I'm doing
as "working around it", but "fixing the tools" is not. As if crowded
code is the ultimate goal.

>> Plus, [: each | each doSomething] is consistent with method signatures, an anonymous selector.
>
> Emerson's quote regarding consistency applies. Sorry, could not resist ;)

Cheap shot.

Bob Arning-2

Re: Code formatting patterns

In reply to this post by Bob Arning-2

I've added a couple of options for emphasizing comments.

Cheers,
Bob

On 10/8/13 8:47 PM, Jecel Assumpcao Jr. wrote:

Bob Arning wrote:

Not sure you need special magic key. Comments know where they are
in the text, but could be displayed just about anywhere. Some experiments
underway at:

http://69.251.218.6:9116/split

That looks pretty good!

For a very compact Smalltalk that I designed, I didn't add comments to
the language itself but rather had this method for Points:

comment: explanation on: expression
  ^ expression

which allowed code like:

a := b + (15@15 comment: 'this is scaled for 32 bit words' on: c*4)

This would work with a very simple text editor and would give the
correct result with a very dumb compiler. But you could have a smarter
compiler notice that the receiver is a constant object and optimize the
message send away. And a fancier editor could show just:

a := b + (c*4)

with the expression in parenthesis having a slightly different
background color, so when you passed the cursor over it the text 'this
is scaled for 32 bit words' would appear at the indicated offset (15@15)
from the bottom left of the left parenthesis.

Two advantages of this scheme were that the comment could be any object
at all, and not just Strings, and that the comment refers to a whole
code fragment and not just to a single point in the code text.

-- Jecel

timrowledge

Re: Code formatting patterns

In reply to this post by Bert Freudenberg

On 09-10-2013, at 1:34 AM, Bert Freudenberg <[hidden email]> wrote:

>
> On 08.10.2013, at 23:46, tim Rowledge <[hidden email]> wrote:
>
>>
>> On 08-10-2013, at 2:14 PM, Eliot Miranda <[hidden email]> wrote:
>>>
>>> So what does a file-out look like? What's the textual/interchange format e.g. in a Monticello package?
>>
>> Not having looked at Tobias' stuff yet, I'm going to guess that one could use the same style-embedding that we already have
>
> ... except that gets dropped by MC.

what was that earlier comment about fixing the tools?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Hardware: The parts of a computer system that can be kicked.

Tobias Pape

Re: Code formatting patterns

In reply to this post by Bert Freudenberg

> Am 09.10.2013 um 10:34 schrieb Bert Freudenberg <[hidden email]>:
>
>
>> On 08.10.2013, at 23:46, tim Rowledge <[hidden email]> wrote:
>>
>>
>>> On 08-10-2013, at 2:14 PM, Eliot Miranda <[hidden email]> wrote:
>>>
>>> So what does a file-out look like? What's the textual/interchange format e.g. in a Monticello package?
>>
>> Not having looked at Tobias' stuff yet, I'm going to guess that one could use the same style-embedding that we already have
>
> ... except that gets dropped by MC.
>

yeah, for our tools, we re-enabled that.
the source is Text then and no pure String.
At first the compiler was confused, but a few
well-thrown #asString’s made everyone happy
again. But I understand methods with style are
strange or even confusing. Should we try that out?

best
-Tobias
--
Tobias Pape
sent from a mobile device

> - Bert -
>
>
>

Levente Uzonyi-2

Re: Code formatting patterns

In reply to this post by Bert Freudenberg

On Wed, 9 Oct 2013, Bert Freudenberg wrote:

> On 08.10.2013, at 23:02, Chris Muller <[hidden email]> wrote:
>
>> My gripe with [:each | each doSomething] is that word-selection then includes the colon, which is a pain when you want to Command+h, Command+g it.
>
> Now that sounds like it would be easy to fix, no? We should fix the tools, not work around them.
>
>> Plus, [: each | each doSomething] is consistent with method signatures, an anonymous selector.
>
> Emerson's quote regarding consistency applies. Sorry, could not resist ;)

If we could get rid of that vertical bar... :)

Levente

>
> - Bert -
>
>
>

Francisco Garau-2

Re: Code formatting patterns

On 9 Oct 2013, at 23:22, Levente Uzonyi <[hidden email]> wrote:

> On Wed, 9 Oct 2013, Bert Freudenberg wrote:
>
>> On 08.10.2013, at 23:02, Chris Muller <[hidden email]> wrote:
>>
>>> My gripe with [:each | each doSomething] is that word-selection then includes the colon, which is a pain when you want to Command+h, Command+g it.
>>
>> Now that sounds like it would be easy to fix, no? We should fix the tools, not work around them.
>>
>>> Plus, [: each | each doSomething] is consistent with method signatures, an anonymous selector.
>>
>> Emerson's quote regarding consistency applies. Sorry, could not resist ;)
>
> If we could get rid of that vertical bar... :)
>

Or add brackets around each method definition and a vertical bar to separate the selector... It would make a nice chunk format!

Point >> [x: aNumber | x := aNumber]

Bert Freudenberg

Styled code (was: Code formatting patterns)

In reply to this post by Tobias Pape

On 2013-10-09, at 23:50, Tobias Pape <[hidden email]> wrote:

> Am 09.10.2013 um 10:34 schrieb Bert Freudenberg <[hidden email]>:
>>
>> On 08.10.2013, at 23:46, tim Rowledge <[hidden email]> wrote:
>>>
>>> On 08-10-2013, at 2:14 PM, Eliot Miranda <[hidden email]> wrote:
>>>>
>>>> So what does a file-out look like? What's the textual/interchange format e.g. in a Monticello package?
>>>
>>> Not having looked at Tobias' stuff yet, I'm going to guess that one could use the same style-embedding that we already have
>>
>> ... except that gets dropped by MC.
>>
>
> yeah, for our tools, we re-enabled that.
> the source is Text then and no pure String.
> At first the compiler was confused, but a few
> well-thrown #asString’s made everyone happy
> again. But I understand methods with style are
> strange or even confusing. Should we try that out?
>
> best
> -Tobias

I'd like that. Having rich text as source code used to be a pretty nifty feature. But after we switched to MC and turned on syntax highlighting it did not get used any more.

- Bert -

Tobias Pape

Re: Styled code (was: Code formatting patterns)

Hi
On 10.10.2013, at 09:41, Bert Freudenberg <[hidden email]> wrote:

> On 2013-10-09, at 23:50, Tobias Pape <[hidden email]> wrote:
>
>> Am 09.10.2013 um 10:34 schrieb Bert Freudenberg <[hidden email]>:
>>>
>>> On 08.10.2013, at 23:46, tim Rowledge <[hidden email]> wrote:
>>>>
>>>> On 08-10-2013, at 2:14 PM, Eliot Miranda <[hidden email]> wrote:
>>>>>
>>>>> So what does a file-out look like? What's the textual/interchange format e.g. in a Monticello package?
>>>>
>>>> Not having looked at Tobias' stuff yet, I'm going to guess that one could use the same style-embedding that we already have
>>>
>>> ... except that gets dropped by MC.
>>>
>>
>> yeah, for our tools, we re-enabled that.
>> the source is Text then and no pure String.
>> At first the compiler was confused, but a few
>> well-thrown #asString’s made everyone happy
>> again. But I understand methods with style are
>> strange or even confusing. Should we try that out?
>>
>> best
>> -Tobias
>
> I'd like that. Having rich text as source code used to be a pretty nifty feature. But after we switched to MC and turned on syntax highlighting it did not get used any more.

The problem is NOT MC.
MC merely serializes what it gets… if it's String, it serializes Strings
if it's text, it serializes text. (Which _isn't_ true for the sources.st,
tho… doable there, but that is an entirely different story).

The problem I see is syntax highlighting. I personally want that.
But, eg, inside comments I probably want to be free to do what I like.
Second problem: when I style literal strings, do they get Text (that
would be soooo cool) or stay they strings? Also, what style is
the syntax highlighter allowed to remove?

Best
-Tobias

signature.asc (210 bytes) Download Attachment

Eliot Miranda-2

Re: Styled code (was: Code formatting patterns)

On Thu, Oct 10, 2013 at 1:21 AM, Tobias Pape <[hidden email]> wrote:

Hi

On 10.10.2013, at 09:41, Bert Freudenberg <[hidden email]> wrote:

> On 2013-10-09, at 23:50, Tobias Pape <[hidden email]> wrote:
>
>> Am 09.10.2013 um 10:34 schrieb Bert Freudenberg <[hidden email]>:
>>>
>>> On 08.10.2013, at 23:46, tim Rowledge <[hidden email]> wrote:
>>>>
>>>> On 08-10-2013, at 2:14 PM, Eliot Miranda <[hidden email]> wrote:
>>>>>
>>>>> So what does a file-out look like? What's the textual/interchange format e.g. in a Monticello package?
>>>>
>>>> Not having looked at Tobias' stuff yet, I'm going to guess that one could use the same style-embedding that we already have
>>>
>>> ... except that gets dropped by MC.
>>>
>>
>> yeah, for our tools, we re-enabled that.
>> the source is Text then and no pure String.
>> At first the compiler was confused, but a few
>> well-thrown #asString’s made everyone happy
>> again. But I understand methods with style are
>> strange or even confusing. Should we try that out?
>>
>> best
>> -Tobias
>
> I'd like that. Having rich text as source code used to be a pretty nifty feature. But after we switched to MC and turned on syntax highlighting it did not get used any more.

The problem is NOT MC.
MC merely serializes what it gets… if it's String, it serializes Strings
if it's text, it serializes text. (Which _isn't_ true for the sources.st,
tho… doable there, but that is an entirely different story).

+1.

The problem I see is syntax highlighting. I personally want that.
But, eg, inside comments I probably want to be free to do what I like.
Second problem: when I style literal strings, do they get Text (that
would be soooo cool) or stay they strings? Also, what style is
the syntax highlighter allowed to remove?

Can you say preferences? Clearly, if the system can support styled code it can support auto-formatting or auto-syntax-highlighting. But if one's feeling get hurt when someone reformats a method one has worked on when they make a trivial change, think how pissed one is going to be when one;s beautifully styled text gets auto-syntax-highlighted when someone makes a fix.

Personally I find syntax highlighting a must-have; it makes a huge difference in both readability /and/ writability. I used to not like it finding it gaudy (I never used it when I worked on VisualWorks). But once I'd spent a few months with it I started to find it really, really potent.

In Newspeak we use syntax highlighting, but aestheticians (who I respect) have chosen a particularly muted scheme, with black, grey and blue as essentially the only colours. I find this code harder to read and write than the gaudy squeak code with its greens and reds and blues and blacks.

For as long as I can remember, working in Smalltalk teams, people have disagreed passionately about formatting. Kent Beck wrote a decent book which is a lot about formatting (and being a visual thinker I love rectangular block), but it doesn't sway many people. So I would lean towards syntax highlighting and auto-formatting and away from fancier manual styling options. To be clear I'm for hyper-links and richer comment formats, even floating comments, if they can be serialized and manually edited easily. But I do think focussing on adding non-functional, purely aesthetic formatting options is heading for a ton of communal pain. For me it doesn't fit a communal system.

--
best,

Eliot

123