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