You're doing it wrong, Ryan.
You should teach them cmd/ctrl+alt+f, and you should teach them that
the editor knows better than they do, so if it indents things 'funny',
then their code is broken. "Solving" their lack of understanding by
indoctrinating them with the 'braces' everywhere mantra is an anti-
pattern.
NB: Nice straw-man, Jess. Nobody shoves an else clause on the same
line as the corresponding if, even braces-haters like me.
On Sep 10, 4:32 am, Ryan Waterer <aguitadel...@gmail.com> wrote:
> While experienced programmers might not worry about the braces on a single
> line, they become invaluable to any junior programmers. I've trained a few
> in which they couldn't understand why the following code segment simply
> stopped working. (Let's not even start a discussion about
> System.out.println as a valid debugging tool, ok? This is just an example
> of a n00blet mistake )
>
> for (int y = 0; y < lines; y++)
> for (int x = 0; x < columns; x++)
> System.out.println("The sum is: " + sum);
> sum += cells[y][x];
>
> I agree that the braces add a bit of "clutter" to the visual look and feel
> of code. However, I feel that it helps with the overall maintainability of
> the code and therefore, I disregard the way that it looks.
>
> --Ryan
>
>
>
> On Wed, Sep 9, 2009 at 8:24 PM, Jess Holle <je...@ptc.com> wrote:
> > I'll agree on the newlines and indents, but the braces are silly.
>
> > One might debate the extra whitespace inside the ()'s, but I find it more
> > readable with the whitespace -- to each his/her own in that regard.
>
> > TorNorbye wrote:
>
> > On Sep 9, 5:27 pm, Reinier Zwitserloot <reini...@gmail.com>
> > <reini...@gmail.com> wrote:
>
> > Here's a line from my code:
>
> > for ( int y = 0 ; x < lines ; y++ ) for ( int x = 0 ; x < columns ; x+
> > + ) sum += cells[y][x];
>
> > I guess that's where we disagree.
>
> > for (int y = 0; y < lines; y++) {
> > for (int x = 0; x < columns; x++) {
> > sum += cells[y][x];
> > }
> > }
>
> > is IMHO better because:
> > (a) I can see immediately that I'm dealing with a nested construct
> > here, and that's it's O(n^2)
> > (b) I can more easily set breakpoints on individual statements of this
> > code while debugging - and similarly other "line oriented" operations
> > (like quickfixes etc) get more cluttery when it's all on one line.
> > Profiling data / statement counts / code coverage highlighting for the
> > line is also trickier when you mash multiple statements into one line.
> > (c) I think it's less likely that I would have made the "x < lines"
> > error that was in your code when typing it this way because the
> > handling of y and x were done separately on separate lines (though
> > this is a bit speculative)
> > (d) I removed your spaces inside the parentheses, because they are
> > Bad! Bad!
>
> > (Ok c and d are padding)
>
> > I am -not- looking to minimize the number of lines needed to express
> > code. If I wanted that, I'd be coding in Perl. I deliberately add
> > newlines to make the code more airy and to group logical operations
> > together. I always insert a newline before the final return-statement
> > from a function etc.
>
> > I think the extra vertical space you've gained, which arguably could
> > help you orient yourself in your code by showing more of the
> > surrounding context, is lost because the code itself is denser and
> > more difficult to visually scan.
>
> > Oh no, a formatting flamewar -- what have I gotten myself into?
>
> > -- Tor
>
> > P.S. No tabs!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
