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