Re^5: Tabs vs Spaces lets give this a go

[tilly]

End of line indentation has a number of problems. I suggest reading Code Complete for more. Using a 2-space indent I would write the above (assuming it is long) as:

my $lmao
  = $wtf
    ? 'omg'
    : 'lol';

and, as you can see, this can be done with only tabs on the left.

Not that I use tabs - I dislike them as well - but saying you can't use tabs because you use an indentation style that I dislike isn't going to convince me. (Though if you use that indentation style, then I agree that you should not use tabs.)

[demerphq]

Ive never liked or agreed with the Code Complete on this subject. The argument tends to be "its costly (in terms of time and effort) to modify/update". However I personally find that often in that time when im fiddling with spaces to get the indenting right im also thinking and analysing about the bigger picture. So getting things lined up is to me the equivelent of idly doodling while I think about something more complex.

And I find that yours is nearlly illegible, wheras the OPS is very clear. If I was working on that line of code there is a very good chance I would reformat it just to ensure that it does what i think its meant to do. The (apparent) lack of structuring in the line is a code-smell to me that would make me immediately wonder what the story was.

I find that ternary ops are most legible when they follow the structure:

   $target = (cond)
           ? option1
           : option2;

Except in C where I would write it:

   target = (cond) ?
            option1 :
            option2 ;

A difference that I put down to perl being trailing semicolon tolerant, and C being trailing semicolon intolerant.

So while I have over time come to agree with Code Complete about many of its arguments and suggestions, I have to say that ternary ops are NOT a place I think they apply.

BTW, I agree with your general comments in your other replies in the thread. I just disagree about the utility of lining stuff up in code. I find it often pays for itself, but it shouldnt be done neurotically. Theres a balance to be found I think. And its not "never line stuff up" and its not "always line stuff up", to me its "sometimes stuff should be lined up".

[tilly]

Actually the argument that convinces me is not the difficulty of updating code, but rather the speed with which you indent very, very far. I'm a strong believer in keeping code indented to no more than 80 characters (less if possible), and end of line indents combined with long variable names can make the indentation grow fast.

And the biggest reason why I care about line widths is that I like to fit as much code as possible on the screen at once. I can fit just about 3 terminals on my screen at work side by side at 80 characters wide. (There is a small overlap, but it is liveable.)

In any case, I don't write many ternary ops, so I format those this way out of consistency. It is more an issue with function calls, which I also format in one level of indent, plus another for the comma. That is I format things like:

  long_function_name(
      $argument1
    , $argument2
    , $argument3
  );

(Yes, I usually use a 2-space indent.) versus something like this

  long_function_name( $argument1
                    , $argument2
                    , $argument3
                    );

Incidentally I'm curious about your C example. According to my rusty memory, C should be fine with either format. A language with semi-optional semicolons (like Ruby or JavaScript) has to be formatted the other way, but I thought C could format either way.

[demerphq]

but rather the speed with which you indent very, very far.

Agreed. I might not necessarily line up the branches right under the '=' for a very long name, instead I'd probably do a single indent. I also would format the function names similarly to you, although would probably, assuming the $arguments werent too long, do

 long_function_name( $argument1, 
    $argument2, $argument3 );

or possibly

 long_function_name( $argument1, 
    $argument2, $argument3 
 );

Related to this, and to your comment

Incidentally I'm curious about your C example. According to my rusty memory, C should be fine with either format. A language with semi-optional semicolons (like Ruby or JavaScript) has to be formatted the other way, but I thought C could format either way.

You can format either way, its whitespace tolerant. The issue is that I think C programmers tend to right scan lines for legal tokens, something like the charclass /[(){};,"?:]/ ( Anyway, thats my theory. :-), whereas it looks like you (maybe due to other language experience) are a bit more interested in the start of the line. Even in perl I'd rarely put a comma on the start of a line, although in perl I often put the concatenation dot on the start of the line.

It feels to me that this is a language issue, and that the various subtleties of the language draw people toward certain styles. For instance hungarian notation feels very strange in perl but not at all in C or VB.