View mode: basic / threaded / horizontal-split · Log in · Help
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
> 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=-
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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
12 13 14 15 16 17 18 19 20
Top | Discussion index | About this forum | D home