On Tue, Oct 8, 2013 at 2:05 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> Not only comments, literal formatting is also important...
> If I want to put line breaks and tabs inside a #( ... ), the formatter
> shall not break it.
> If I want to write 2r0110, there must be a reason, and the formatter shall
> not normalize to 6.
>

Yes, very important point.


>
>
> 2013/10/8 Chris Muller <asqueaker at gmail.com>
>
>> > On Mon, Oct 7, 2013 at 3:01 AM, Bert Freudenberg <bert at freudenbergs.de>
>> > wrote:
>> >>
>> >> On 2013-10-06, at 20:25, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>> >>
>> >> > hence we're left with the war between visual thinkers (rectangular
>> >> > blocks) and verbal thinkers (pascal formatting).  just throwing wood
>> on the
>> >> > fire ;-)
>> >>
>> >> I very much like rectangular blocks as the general formatting rule;
>> this
>> >> is how Smalltalk code looks "naturally" to me. However, you must *not*
>> put a
>> >> space inside the brackets because then they draw too much attention,
>> >> standing there on their own:
>> >>
>> >>         [this is
>> >>         rectangular]
>> >
>> >
>> > Ian Piumarta and I are anal enough to prefer
>> >
>> >         [this is
>> >          rectangular
>> >          and nicely indented]
>> >
>> > ;-)
>> >
>> >>
>> >> vs
>> >>
>> >>         [ this is not
>> >>         as rectangular ]
>> >
>> >
>> > yuck.  Ugly as sin.  Hate the extra whitespace.  I like
>> asSortedCollection:
>> > [:a :b| a < b], *not* *horrible* [ :a :b |, or even *worse*, [ : a : b |
>> > (argh)... ;-)
>>
>> I guess there's no accounting for taste.  :)
>>
>> 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.  Plus, [: each | each doSomething] is consistent with
>> method signatures, an anonymous selector.
>>
>> >> Conventional wisdom says in that case one should refactor the method
>> >> because it got too complex, which I agree to if there is a part that
>> makes
>> >> sense as its own method. However, I personally don't like one-off
>> private
>> >> methods just for the sake of simplifying one method. These typically
>> need
>> >> many arguments, have perhaps multiple return values, so the resulting
>> >> complexity is not worth doing it.  Or am I missing something?
>> >
>> > Nope.  +1.
>> >
>> > If it weren't for comments (and comments are /really/ important) we'd
>> have
>> > implemented a parameterised formatted by now that auto-formatted code
>> to the
>> > preferences of the reader and this would all be moot.  But without a
>> good AI
>> > I don't see how to spot and preserve while reformatting multi-line
>> comments,
>> > comments with diagrams in them, etc, etc, etc.
>>
>> Right the formatter butchers comments is all the more reason I lean
>> toward composing methods to expose more meaning.  Auto-formatting is
>> too valuable to give up.
>>
>>
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131008/8da6dc8c/attachment.htm