[squeak-dev] Styled code (was: Code formatting patterns)

Eliot Miranda eliot.miranda at gmail.com
Thu Oct 10 12:36:47 UTC 2013


On Thu, Oct 10, 2013 at 1:21 AM, Tobias Pape <Das.Linux at gmx.de> wrote:

> Hi
> On 10.10.2013, at 09:41, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> > On 2013-10-09, at 23:50, Tobias Pape <Das.Linux at gmx.de> wrote:
> >
> >> Am 09.10.2013 um 10:34 schrieb Bert Freudenberg <bert at freudenbergs.de>:
> >>>
> >>> On 08.10.2013, at 23:46, tim Rowledge <tim at rowledge.org> wrote:
> >>>>
> >>>> On 08-10-2013, at 2:14 PM, Eliot Miranda <eliot.miranda at gmail.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131010/070a5928/attachment.htm


More information about the Squeak-dev mailing list