On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:
> 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


Have you /actually/ tried this in Visual C#?


Visual C# doesn't use "heuristics" to do format your code... it's not like C++ where everything is ambiguous.


I suggest you give it a try and let the auto-formatter format your code to see what I mean.

On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:
> 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.
>

Believing that one code formatting will inherently be better than what a formatted can do is very similar to the assertion often heard that code generated by the compiler is worse than hand written assembly or many other recurring similar topic coming again and again in dev discussion.

It has been shown more than once that you can beat the compiler on some carefully selected piece of code, but generally speaking, you have not even a small chance to beat it at a program scale or when certain optimizations kicks in. Same goes for the formatter.

As a matter of fact, the time you spend formatting can be better spent elsewhere, and the consistency you win in the process has many benefits : cleaner diffs and easiers merges because you have no formatting conflict. The codebase is consistent, and the tool can even help you by reformatting confusing stuff is clearer ones.

Not to mention that all refactoring tools suffer badly if you don't have a proper formatter : you spent as much time reformatting the code than you would have needed to do the refactoring itself.

On Friday, January 18, 2013 09:12:26 Mehrdad wrote:
> Have you /actually/ tried this in Visual C#?
> 
> Visual C# doesn't use "heuristics" to do format your code... it's not like C++ where everything is ambiguous.
> 
> I suggest you give it a try and let the auto-formatter format your code to see what I mean.

Heuristics aren't the issue. The problem is that formatters inevitably have a strict set of rules about how code is supposed to be laid out, and they don't allow you to break them. There are times when it's just plain ugly to follow the formatting rules exactly, and the rules need to be bent or broken in order to make the code clean and legible. I have never seen a code formatter which could do anything like that. Certainly, the more powerful and flexible the code formatter is in terms of the rules that you can give it, the fewer such problems you run into, but I'd never expect a formatter to be able to avoid the problem entirely.

- Jonathan M Davis

> Maybe I should invent a programming language in which color has semantic
> value. And fonts. :-P

Sort of :-)

http://www.colorforth.com/primer.htm

-=mike=-

On 1/17/2013 5:59 PM, 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.

I might add that trying to find the right way to format code is a non-trivial exercise I go through all the time. It matters how it's laid out.

One of my frustrations with C++ is I was never able to figure out a way to format its template code into an aesthetically pleasing format.

On 2013-01-18 08:18, Jonathan M Davis wrote:

> 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.

Eclipse has a pretty darn good code formatter. It formatted the code exactly like I wanted to, except in one or two cases but that's usually because I broke my own rules.

Example, this is usually how I format a switch statement:

switch (value)
{
    case 1:
        // code
    break;

    case 2:
        // code
    break;
}

But on occasion, when I have only a short single line expression and many cases I usually format it like this:

switch (value)
{
    case 1: a = 2; break;
    case 2: a = 3; break;
    case 3: a = 4; break;
}

The formatter will break that.

-- 
/Jacob Carlborg

On 1/17/2013 11:58 PM, Artur Skawina wrote:
> Sane, but badly formatted code is much preferable to bad, but pretty code.

Offhand, I can't remember ever running across bad but pretty code.

On Friday, 18 January 2013 at 08:13:48 UTC, deadalnix wrote:
> Believing that one code formatting will inherently be better than what a formatted can do is very similar to the assertion often heard that code generated by the compiler is worse than hand written assembly or many other recurring similar topic coming again and again in dev discussion.
>
> It has been shown more than once that you can beat the compiler on some carefully selected piece of code, but generally speaking, you have not even a small chance to beat it at a program scale or when certain optimizations kicks in. Same goes for the formatter.
>
> As a matter of fact, the time you spend formatting can be better spent elsewhere, and the consistency you win in the process has many benefits : cleaner diffs and easiers merges because you have no formatting conflict. The codebase is consistent, and the tool can even help you by reformatting confusing stuff is clearer ones.
>
> Not to mention that all refactoring tools suffer badly if you don't have a proper formatter : you spent as much time reformatting the code than you would have needed to do the refactoring itself.

When reading your post, I thought of replacing the concept of an automatic source code formatter with an automatic garbage collector. We've seen this kind of debate before, with the same sort of arguments in favor and against.

It could very well be that so long as the implementation is good, the idea of a standardized enforced format may be better than the current alternative. It's like the difference between machine tooling vs what you get from an anvil and hammer approach. Consistency vs inconsistency.

--rt

On 01/18/2013 09:48 AM, Walter Bright wrote:
> On 1/17/2013 11:58 PM, Artur Skawina wrote:
>> Sane, but badly formatted code is much preferable to bad, but pretty
>> code.
>
> Offhand, I can't remember ever running across bad but pretty code.

Some of the worst code I have seen has been consistently formatted.

On Friday, January 18, 2013 09:47:31 Jacob Carlborg wrote:
> On 2013-01-18 08:18, Jonathan M Davis wrote:
> > 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.
> 
> Eclipse has a pretty darn good code formatter. It formatted the code exactly like I wanted to, except in one or two cases but that's usually because I broke my own rules.
> 
> Example, this is usually how I format a switch statement:
> 
> switch (value)
> {
>      case 1:
>          // code
>      break;
> 
>      case 2:
>          // code
>      break;
> }
> 
> But on occasion, when I have only a short single line expression and many cases I usually format it like this:
> 
> switch (value)
> {
>      case 1: a = 2; break;
>      case 2: a = 3; break;
>      case 3: a = 4; break;
> }
> 
> The formatter will break that.

But my point is precisely that there are times that you need to break the formatting rules in order to make the code look code and be appropriately legible. The formatter will probably do a fantastic job of being consistent, but that's the problem. _Most_ of the time, it will do the right thing, but there are times when you need to break the formatting rules, and that just doesn't work when a program is formatting the code for you.

I had to use eclipse's formatter at one of the places that I worked, because all commits had to follow, and I hated it. Code formatters are not the ticket to good looking code. Quite the opposite, in fact.

- Jonathan M Davis