I think the best way to indent is to have the braces on separate lines
and indentation levels and then put semicolons after the tabs to make
the indentation level more visible:
for (int y = 0; y < lines; y++)
{
; for (int x = 0; x < columns; x++)
; {
; ; sum += cells[y][x];
; }
}
Pretty, isn't it?
Screw all the empty statement warnings!
Peter
Reinier Zwitserloot wrote:
> YES! Casper brought tabs into it! Wahoo! We've got all the ingredients
> here to beat the post count of the checked exception thread. It ran
> for over 150 posts. Can we beat it?
>
> I'll toss this one into the ring:
>
> The ONLY right indentation scheme is to use tabs for indentation and
> spaces for spacing. The following two rules may never ever be broken:
>
> 1. The character in front of a tab must be either (A): Start of File,
> (B) another tab, (C) a newline. A tab anywhere else is an error.
> 2. 1 tab per semantic indentation.
> 3. Yes, this means you get mixed tabs and spaces if you want to line
> up something (such as a line continuation). For all mixed cases, it's
> always all tabs first, then all spaces.
>
> As a natural result of these rules, changing tab size doesn't change
> the way your code looks at all, other than in the most superficial
> manner: The relative obviousness of each indent. That is dependent on
> your font and screen size anyway, so it makes sense to leave the
> rendering of it up to the editor, instead of hardcoding it.
>
> I dare you to resist replying to this :)
>
> NB: Tongue in cheek folks. The only right way to indent is whatever
> you're comfortable with. The only wrong way is to get religious about
> it.
>
> On Sep 10, 3:50 am, Casper Bang <casper.b...@gmail.com> wrote:
>
>> I agree with Tor, except drop the braces:
>>
>> for (int y = 0; y < lines; y++)
>> for (int x = 0; x < columns; x++)
>> sum += cells[y][x];
>>
>> It reads just as easily and there's a reason why we already indented
>> the code (with a since tab rather n spaces; how an indentation is
>> rendered is really up to the editor/viewer and the preferences you may
>> have).
>>
>> I often think there must be some neat visual way to show nesting and
>> scoping better than we do today, i.e. by drawing a frame around,
>> drawing with a darker color or so. NetBeans can already do AST
>> selection though Shift + Alt + Comma/Dot but I don't think it really
>> unleashes the full potential before the user can see better what the
>> IDE sees.
>>
>> /Casper
>>
>> On 10 Sep., 03:04, TorNorbye <tor.nor...@gmail.com> wrote:
>>
>>
>>
>>
>>> On Sep 9, 5:27 pm, Reinier Zwitserloot <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
-~----------~----~----~----~------~----~------~--~---
