Well...
For starters, stack traces report against line numbers and line numbers
are meaningless is you can't agree on what's on which line.
Once this was solved or even limiting oneself to formatting within a
line, it might be nice if indentation and formatting would be just while
one was editing or viewing code and to suit your own preferences. This
assumes (1) everyone is using such a smart tool all the time and (2)
that the indentation/formatting engine is /really /smart [every free
indentation/formatting engine I've seen needed manual help to produce
results I could live with -- I've not paid for an engine though...].
Things really fall apart on (1). There are at least 3 IDEs with major
usage. Apart from this, I and most folk I know do a lot of quick "in
the trenches" reading of code snippets in e-mail, via dumb but quick
editors (e.g. vim, TextPad, etc), and via various web-based browsing
tools (e.g. OpenGrok). *All* of these would have to be smart enough to
reformat to your indentation/formatting tastes -- else the whole thing
falls on its head. I don't see that happening, so I see us always at
the ascii (or maybe Unicode) symbol level -- it's the common denominator
all tools can agree on, albeit necessarily the lowest common denominator.
Joshua Marinacci wrote:
> RANT!
>
> Why, in the 21st century, are we still writing code with ascii symbols
> in text editors, and worried about the exact indentation and whether
> to use tabs, spaces, etc?!!
>
> Since the IDE knows the structure of our code, why aren't we just
> sharing ASTs directly, letting your IDE format it to your desire, and
> only sharing the underlying AST with your fellow developers. Encoding,
> spaces, braces, etc. is a detail that only matters when presented to
> the human.
>
> What we do today is like editing image files from the commandline!
>
> On Sep 9, 2009, at 7:32 PM, Ryan Waterer 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
>> <mailto: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>
>>> <mailto: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
-~----------~----~----~----~------~----~------~--~---
