There is a part of me that likes this idea (mostly the part of me that
has to read other people's code). The other part of me would mourn the
loss of the ability to express something by bending the general style
rules.
I've been using GWT recently and have struggled with writing clear
code for constructing views. What I'm experimenting with in some cases
is to make the code a visual representation of the layout. This began
with and works very nicely for VerticalPanel. In my current
guidelines, adding an element to a VerticalPanel is not allowed to
take more than one line. If it's something simple like a Label that I
don't need to retain access to, I just construct a new one inline.
Otherwise, I write a method to create the element. For example:
VerticalPanel panel = new VerticalPanel();
panel.add(new Label("Login"));
panel.add(makeLoginForm());
panel.add(makeLoginButton());
panel.add(makeForgotPasswordLink());
This also has the advantage of naming the pieces of the UI. While this
is also a slight burden, I'm generally in favor of it for the sake of
clarity.
I then applied this to a Grid. In the specific case, it was a simple
2x2 grid:
Grid grid = new Grid(2, 2);
grid.setWidget(0, 0, new Label("User ID")); grid.setWidget
(0, 1, usernameBox);
grid.setWidget(1, 0, new Label("Password")); grid.setWidget
(1, 1, passwordBox);
Note that with a fixed width font, the 2nd statements line up with
each other. I'm not normally a fan of putting multiple statements on
the same line, but in this case, it makes the intent of the code very
clear. (The multiple statements, of course, still need to reasonably
fit on one line of text.)
While I'm very particular about consistent style, it's nice to be able
to be creative when the situation calls for it.
(BTW, I've usually preferred spaces instead of tabs, but tabs would
make it easier to make sure that the statements stay lined up. In
fact, using tabs explicitly expresses the intent for them to line up.)
-Brian
On Sep 9, 11:10 pm, Joshua Marinacci <[email protected]> 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 <[email protected]> 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 <[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
-~----------~----~----~----~------~----~------~--~---
