On Friday, 18 January 2013 at 01:59:18 UTC, Walter Bright wrote:
> On 1/14/2013 3:19 PM, Timon Gehr wrote:
>> It is funny how statements about beauty of code tend to overemphasize the
>> importance of trivial formatting rules. This is completely irrational.
>> Formatting is a part of the process that could be trivially automated. It is not
>> what the substance is.
>
> Pedantically, you are correct.
>
> But in practice, I find over and over again that carefully formatted code tends to go hand in hand with well designed code.
>
> It's like internet postings.


Also like spam vs. not spam email

On 01/18/13 02:59, Walter Bright wrote:
> On 1/14/2013 3:19 PM, Timon Gehr wrote:
>> It is funny how statements about beauty of code tend to overemphasize the importance of trivial formatting rules. This is completely irrational. Formatting is a part of the process that could be trivially automated. It is not what the substance is.
> 
> Pedantically, you are correct.
> 
> But in practice, I find over and over again that carefully formatted code tends to go hand in hand with well designed code.
> 
> It's like internet postings. If you see a posting in ALL CAPS, or all lower case, or sloppy grammar/spelling, or long runon sentences, or no paragraph breaks, etc., it's almost certainly devoid of interesting content. If you see an electronics board with a rat's nest of wires and sloppy construction, odds are high it won't work. If you see a neatly laid out board, odds are it works.
> 
> And so on for just about every engineering/construction work.

This is one of the reasons why automatic code formatting is such a bad idea.

artur

On Thu, Jan 17, 2013 at 05:59:13PM -0800, Walter Bright wrote: [...]
> But in practice, I find over and over again that carefully formatted code tends to go hand in hand with well designed code.
> 
> It's like internet postings. If you see a posting in ALL CAPS, or all lower case, or sloppy grammar/spelling, or long runon sentences, or no paragraph breaks, etc., it's almost certainly devoid of interesting content. If you see an electronics board with a rat's nest of wires and sloppy construction, odds are high it won't work. If you see a neatly laid out board, odds are it works.
> 
> And so on for just about every engineering/construction work.

This is interesting. I think it holds not just for code formatting, but with the overall design of the code as well. When you see unfocused module APIs, leaky abstractions, and copy-n-pasted code, you know you're in for a world of pain, no matter how beautifully the code may be formatted. (Although generally, such symptoms often also go along with poor formatting. But I've seen horribly-designed code that was superficially very prettily formatted.) When you see a function that converts IPv6 addresses to strings and then uses string comparisons for subnet checking, you know that the rest of the code is going to be equally bad, if not worse.

And on and on it goes.


T

-- 
Why ask rhetorical questions? -- JC

On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
> This is one of the reasons why automatic code formatting is such a bad idea.
>
> artur



In what language? In C# it's actually a fantastic idea.

On Friday, January 18, 2013 07:45:34 Mehrdad wrote:
> On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
> > This is one of the reasons why automatic code formatting is such a bad idea.
> > 
> > artur
> 
> In what language? In C# it's actually a fantastic idea.

In _any_ language. Inevitably, the formatter ends up totally mangling at least some of the lines. In my experience, any attempt to be super strict with the formatting rules (as an automatic code formatter must be) results in ugly code. A basic set of formatting rules helps the code be consistent and look good, but there are always corner cases where the rules must be bent or broken in order to make the code appropriately legible. And it requires having a human do the formatting to get that kind of flexibility.

- Jonathan M Davis

On Friday, 18 January 2013 at 06:45:37 UTC, Mehrdad wrote:
> On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
>> This is one of the reasons why automatic code formatting is such a bad idea.
>>
>> artur
>
>
>
> In what language? In C# it's actually a fantastic idea.

Well.. :)
enum E
{
  S      = 0x01,
  Longer = 0x10,
}

After:
enum E
{
  S = 0x01,
  Longer = 0x10,
}

Any manual formatting like lining up arguments is always lost. Following the recommended style guide for a language by hand isn't that big a feat, and allows to break it where you feel your own style is superior.

On 2013-01-18 08:21, simendsjo wrote:

> Well.. :)
> enum E
> {
>    S      = 0x01,
>    Longer = 0x10,
> }
>
> After:
> enum E
> {
>    S = 0x01,
>    Longer = 0x10,
> }
>
> Any manual formatting like lining up arguments is always lost. Following
> the recommended style guide for a language by hand isn't that big a
> feat, and allows to break it where you feel your own style is superior.

I'm pretty sure Eclipse even has an option to align assignments like these.

-- 
/Jacob Carlborg

On Friday, 18 January 2013 at 07:21:48 UTC, simendsjo wrote:
> On Friday, 18 January 2013 at 06:45:37 UTC, Mehrdad wrote:
>> On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
>>> This is one of the reasons why automatic code formatting is such a bad idea.
>>>
>>> artur
>>
>>
>>
>> In what language? In C# it's actually a fantastic idea.
>
> Well.. :)
> enum E
> {
>   S      = 0x01,
>   Longer = 0x10,
> }
>
> After:
> enum E
> {
>   S = 0x01,
>   Longer = 0x10,
> }
>
> Any manual formatting like lining up arguments is always lost. Following the recommended style guide for a language by hand isn't that big a feat, and allows to break it where you feel your own style is superior.

That is completely wrong.

On 01/18/13 07:45, Mehrdad wrote:
> On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
>> This is one of the reasons why automatic code formatting is such a bad idea.
> 
> In what language? In C# it's actually a fantastic idea.

Every language. Not only does it mean that the heuristics mentioned by Walter
can't be used (which isn't the main problem, as the error rate is way too high),
but skipping of the manual (re-)formatting-and-verifications-phase actively
reduces code quality by removing opportunities for extra review, discovery of
refactoring possibilities and reflection.
Sane, but badly formatted code is much preferable to bad, but pretty code. The
former can be easily fixed. Ugly code, that also happens to be bad, will be
found and fixed as part of that process.
Auto formatting loses information which makes spotting the truly bad code harder.

artur

On Friday, 18 January 2013 at 07:19:16 UTC, Jonathan M Davis wrote:
> On Friday, January 18, 2013 07:45:34 Mehrdad wrote:
>> On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
>> > This is one of the reasons why automatic code formatting is
>> > such a bad idea.
>> > 
>> > artur
>> 
>> In what language? In C# it's actually a fantastic idea.
>
> In _any_ language. Inevitably, the formatter ends up totally mangling at least some of the lines.


I guess you've never used Visual C#? Give it a try sometime ;)