Oh, no, Tor. Not a formatting flamewar. It must be a slow day.
I know the inner spaces thing is bad. I decided on it years and years
ago, I've since recanted from my evil ways, but the damn things are so
stuck in my muscle memory I can't get rid of them. Horrible situation
to be in.
Sure, squashing it all into one line gets in the way for line-oriented
stuff, but where does one draw the line? Should I write stuff like
this:
if (x
.equals(
y
.fetchSomething()
) System
.out
.println(
getValue()
);
in order to get maximum benefit from line numbers in exception traces
and quickfix? Apologies for the straw-man; I'm trying to illustrate
this is a gray area and not black and white. Clearly there's a line to
be drawn, and I'm trying to get across that the existence of an if/for/
while does not neccessarily mean its block should neccessarily be the
right place for a line break.
I don't think the notion of spotting complexity such as O(n^2) really
holds - in order to determine such things, you need to analyse ALL of
the source code. quick, what's the order of this thing?
for ( int i = 0 ; i < foo ; i++ ) {
list.removeAll(otherList[i]);
}
You can't even tell without knowing the implemention of list, but most
likely, it'll be north of O(N^2). I have the most experience about
having to deal with QUICKLY writing code, being able to keep the whole
thing in my mind, get an instant feel for existing bugs and time/space
complexity, when I participate in programming contests like the google
code jam, and that's exactly where I pack stuff into a single line
most often if it feels right to do so. Of course, one should question
the relevance of such dinky toy projects compared to serious
programming, so perhaps this observation isn't very relevant.
But let's go back to those breakpoints: In the snippet I showed, I
really doubt I'll ever need a breakpoint. It feels like a single
operation. Sure, if it bugs (and it did, due to my typo!) I'll quickly
split it up into multiple lines (without braces!) so I can breakpoint
it or at least get better granularity out of the line numbers in stack
traces, but that's doable on the fly of course. If the loop 'felt'
heavy then it wouldn't be dumped into one line like that. Perhaps just
the 2 for loops on one line, with the heavy-feeling inner loop
separated. It's more of an artsy thing for me: Some things feel like
they ought to be a single instruction, and other things don't. Like
you I toss blank newlines all over the place in other to separate code
into what I feel make sensible 'paragraphs'.
In other languages one might write (weird java / python / hypothetical
pastiche!):
for ( Coordinate c: new Coordinate(x, y) with int x: 0..width, int y:
0..height ) {
sum += cells.at(c).value;
}
and I bet nobody would bat an eye that the loopy bits of the O(N^2)
loop construct is stuffed into a single line. Which again goes back to
my central point here: for/if are an arbitrary position for demanding
a newline (and braces). A fine rule of thumb, but nothing to get as
excited about as SpikeyOrange did.
On Sep 10, 3:04 am, TorNorbye <[email protected]> wrote:
> On Sep 9, 5:27 pm, Reinier Zwitserloot <[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
