Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why braces around try/catch?

Reply
Thread Tools

Why braces around try/catch?

 
 
Dale King
Guest
Posts: n/a
 
      08-15-2003
In article <(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed)
says...
> Dale King wrote:
> > > I also find that braces emphasize control flow in the program, and I
> > > also think that's a good thing. In addition to that, though, they also
> > > make a bigger production of what is often a simple concept. That's a
> > > bad thing, because it make idiomatic reading of code difficult, and
> > > intrudes on the omprehension process.

> >
> > Once again I conclude the exact opposite. Having a single idiom rather than
> > multiple idioms for the same construct (e.g. if) makes an idiomatic reading
> > of code difficult.

>
> I think we need to clear up the definition of "idiom". You seem to mean
> "syntactical construction", where I'm going a bit higher level, and
> referring to a programmer's use of those language constructs in a
> specific way. For example, the standard for loop for integer indexing:


And I was using it as a way of expressing some desired action with a
syntactical construct. For example, to set a variable to one of 2
different values one idiom would be to use an if-else. Another idiom
would be to use the conditional operator.

In this case, one idiom for doing a conditional is to spell it out with
braces and another is to use a single line. If I only use the single
idiom of spelling out the if's it is always easier to pick out and
identify the conditionals. In other words it makes an idiomatic reading
easier because I only use one idiom.

> You see, there are two elements that go into making a good idiom: it
> must be easily recognizable,


Which is where I fault the single line if. It is not easy to recognize.

> and it must be easy to dismiss the
> idiomatic construction and get to the heart of the matter.


I find that much easier with the verbose if.

> This is, in
> fact, the whole reason that 'for' is better for idiomatic array looping
> than 'while'. There's really not a whole lot of extra typing involved
> in writing:
>
> int i = 0;
> while (i < array.length)
> {
> ...
>
> i++;
> }
>
> but that's not so good for idiomatic reading of the code because the
> idiom is spread out more, and thus more difficult to dismiss after it's
> been recognized and categorized.


And I say its bad because it is not as easily recognized what is
happening as it is with the for. Therefore one should only use a single
idiom for this.

> That seems to me a perfect parallel,
> in fact, as for was specifically introduced as a redundant syntax in the
> language because it's better for concise expression of idiomatic
> elements of the language.


Terseness is not high on my prioirty list. The advantage of the for is
that, in its usual incarnation, it puts all the information about the
"loop control" into one place separated from the the processing done on
each iteration. The while loop intermingles those and separates the
declaration of the variable entirely.

So in my opinion it is not the terseness, but the logical grouping that
is important in the for statement.

> With single line conditionals, the idiomatic elements are generally
> defined more by the context. For example, I frequently find myself
> writing code like the following (which it looks like you'll detest with
> a passion):


You've got that right. For one thing you have many control flow paths
there represented with no structure or visible clues that it is
occurring.

> for (int i = 0; i < array.length; i++)
> {
> if (array[i] == null) continue;
> if (!array[i].isVisible()) continue;
> if (!array[i].needsUpdate()) continue;
>
> // update the member:
> ...
> }
>
> I firmly believe that the three short lines written at the top of the
> loop body, each clearly giving a condition on which we skip this item,
> are more readable that the expanded form:


I would at least for a start change that slightly to show the control
paths

for (int i = 0; i < array.length; i++)
{
if (array[i] == null)
{
continue;
}
else if (!array[i].isVisible())
{
continue;
}
else if (!array[i].needsUpdate())
{
continue;
}
else
{
// update the member:
...
}
}

But that is not how I would write it. Since you can make it more
straightforward by not using the continue and reversing the logic, but
I'll do that further down.

> That's just tedious... not to write, as it really takes no longer to
> write this than the previous form, but to process mentally when I see
> it.
>
> (Incidentally, you may suggest:
>
> if ((array[i] == null)
> || !array[i].isVisible()
> || !array[i].needsUpdate())
> {
> continue;
> }
>
> or even:
>
> if ((array[i] != null)
> && array[i].isVisible()
> && array[i].needsUpdate())
> {
> ...
> }


No, I really don't like complex if conditionals. I find myself more and
more using the refactoring of Introduce Explaining Variable:

http://www.refactoring.com/catalog/i...gVariable.html

So for many complex conditionals I introduce more meaningful variables.
It is probably overkill in this case however. Because there is a
necessary ordering to the conditions, I would make that more explicit in
the code. Here is probably how I might do it eliminating the continue
statements:

for( int i = 0; i < array.length; i++ )
{
Foo element = array[ i ];

if( element != null )
{
if( element.isVisible() && element.needsUpdate() )
{
// update the member:
...
}
}
}

I would much rather see this than your version. This version adds 2 extra
lines, which are for the variable I introduced to provide a name to the
element instead of propogating the array indexing throughout.

I fail to see how anyone would fail to find that more readable than
yours. It greatly simplifies the control flow structure. While I am not
an anti-goto zealot I see no reason to introduce jumps when there is
definitely no need.

Another way to go would be to encapsulate the conditionals into a single
method call and we could then code it as:

for( int i = 0; i < array.length; i++ )
{
if( elementShouldBeUpdated( array[ i ] ) )
{
// update the member:
...
}
}

> and I agree that's better than the second form, but it suddenly requires
> parsing a long complex conditional, involving mentally matching multiple
> levels of nested parentheses. I wonder if I'm alone in thinking that's
> one of the most painful tasks possible in reading code. I far prefer a
> series of parallel, simple statements to a long conditional expression.)


I certainly agree. I rarely ever use a conditional that takes more than
one line. As I said, I prefer to introduce explaining variables. In this
case the calls were self-documenting and not overly long.

> That's a long form of what I meant when I said that shorter forms lend
> themselves to writing code for easier idiomatic reading.


Not proven by this example. I think my version is much easier idiomatic
reading.

> > I like Steve McConnell's idea in Code Complete of layout where he uses
> > abstract pieces of code without text.

>
> I 100% agree with you that this is important, though I didn't recall it
> being in Steve McConnell's books. I thought about this to some depth
> before I wrote the article you're replying to. I almost mentioned it
> there, but I ended up not addressing it... mostly because I didn't trust
> myself to properly explain the idea before going on to explain that I
> don't think it applies.
>
> Now here's why I don't think it applies: it all eventually comes down to
> something I've talked about in this newsgroup before, generally without
> making much of an impression: a gap where abstraction and encapsulation
> [for lack of a better word, but not the practical OO kind of
> encapsulation] don't quite line up, and the developer wants
> encapsulation without the abstraction. Some people just get up on a
> soapbox and proclaim that these situations don't exist; I think those
> people are fooling themselves.
>
> This is going to get somewhat difficult to explain, so please bear with
> me. First some definitions: By encapsulation, I don't mean hiding from
> a language perspective. I just mean a general quality of bundling
> things together and dealing with them as a group. It's actually closely
> related to my discussion of idiomatic reading above: something that's
> encapsulated in this sense is easy to label and put out of mind.
>
> Abstraction is something more than that; it requires encapsulation, but
> it isn't implied by encapsulation. Abstraction is the quality by which
> higher meaning an be assigned to the whole than to the sum of the parts.
> It's basically indicated by the ability to give the whole a name that's
> more expressive than the code that implements it.
>
> Now abstraction indicates a need to refactor something into a named
> method or even class. Mere encapsulation would be very awkward to
> refactor, and requires just shoving it out of consciousness as much as
> possible so that the main point of a piece of code can be understood,
> because the code is still the clearest representation of what's
> happening. Refactoring into another method would require that you try
> to pick an identifier which does as good a job as possible of expressing
> what's in the code, but can never be as good as the code itself. (If you
> can pick an identifier that's better than the code, then you should go
> for it, and the result will be abstraction rather than just
> encapsulation, and you'll have done well to refactor it.)
>
> As an interjection here, this is not all academic. I worked for most of
> this past year with a developer who didn't get this, and tried her
> hardest to generate identifier names for extracted methods that never
> quite lived up to the idea of abstractions. I still have to
> occasionally change part of that code and encounter methods named
> insanely long things, involving lots of 'and' and 'if' and 'while' in
> the identifier, than still never quite accomplish explaining what the
> code does well enough that I avoid the need to go read the method
> anyway.
>
> Now, here's my contention: I don't think it's any worse to "hide" an if
> statement to reduce the impact in a piece of code than to "hide" an if
> statement in a call to a refactored method. If no loops or conditions
> were ever hidden, then all control flow keywords would occur in main!
> Obviously, you'd be in favor of hiding them in extracted methods and
> classes, but for some reason de-emphasizing them in included code
> doesn't sit right with you.


I don't agree with your intentions here. The purpose is not to hide. I
disagree that the intent is to put things out of mind. I see the intent
more to separate things into smaller more digestible units. With an if we
are separating into the unit of what happens when the condition is true,
what happens when it is not true, and what the condition is. This is
separated from the code that surrounds it.

We do this because of the limited size of our skulls. We can only keep
track of a few things at once. I guess this would fall under your meaning
of encapsulation. We want to encapsulate the things we have to keep track
of while reading the code into manageable units. But it seems to me that
you then try to bury or hide those units. They are not out of sight or
mind because they aren't encapsulated they blur into their surroundings.
When I am looking at the update code it is not clear that there are
conditions that have to be fulfilled to get there. Within the update code
you might wonder could the element be null or invisible? You would only
know that by reading the top of the body and parsing it out. In my
version those questions are answered by the context. The update code very
clearly is in the context of not-null, visible and in need of update.

> So in the end, you have to admit that hiding control flow is necessary,
> and you just aren't comfortable with my in-between way of doing it.


No, I do not admit that hiding is necessary just for the sake of hiding.

> I see this as a matter of trying to retain the ability to format code so
> as to convey a message about its meaning.


You want to convey the meaning by hiding it??

> > > if (!canContinue) return;
> > > if (input < -1) return -1;
> > > if (!flag[i][j]) continue;
> > > if (s == null) s = DEFAULT_VALUE;

> >
> > Eeek! The last one might be excusable as it is a simple assignment. But
> > hiding statements like that which are control flow statements is an
> > abomination. I always use braces and the else to show that there is a change
> > in control flow.

>
> Is this beause you think the conditional somehow makes things worse, or
> because you generally dislike statements like break, return, and
> continue. The if doesn't hide a return or continue any more than if it
> appeared on a line by itself, by your rot13-on-the-code standard.


No, I am not a purist that is against them. They (and you can include
throwing an exception as well) cause an *implicit* non-linear jump. If
one can, you should try to make that explict as much as possible, such as
my first example where I used else to make the divergence in control flow
explicit. The usual example is checking method parameters. Instead of

if( parameterBad ) throw ...
// normal flow

I would do it:

if( parameterBad )
{
throw ...
}
else
{
// normal flow
}

Of course there are cases where this really can't be made explicit in a
two-dimensional space, such as the classic example of the search loop.

> In essence, I think the issues are orthogonal. If you didn't mind those
> keywords, there's not additional reason to dislike them when used with
> an if statement in a single-line form. I could be wrong, though.


I don't think they are orthogonal, because they both affect the control
flow. One is implicit and one explicit (as in made visible structurally).
The explicit one can be used to make the implicit one more visible.

> > > It isn't a matter of cost; it's a matter of vertical space
> > > psychologically conveying something about the code, and not wanting to
> > > mislead the reader

> >
> > How can making something clearer be misleaading the reader?

>
> In the same way I can mislead a reader about my intent and what they can
> expect by spending 50 pages explaining the Newtonian physics of bullets
> at the beginning of an action movie script. It just doesn't deserve
> that much attention. Screen space IS attention.


I don't think that applies here. It gets back to your encapsulation. If I
encapsulate that so it can be separated. To continue the bad analogy here
you can include the physics lesson in an appendix.

> > The longer I program, the more I learn that there are fewer and fewer
> > trivial concepts.

>
> And I think the main lesson from software development is that you can't
> think about everything all of the time. Something always has to be
> assumed, which means it's trivial in the context of the current issue.


I addressed this above.
--
Dale King
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      08-15-2003
On Fri, 15 Aug 2003 04:35:11 GMT, Dale King <(E-Mail Removed)> wrote
or quoted :

>So in my opinion it is not the terseness, but the logical grouping that
>is important in the for statement.


Amen brother!

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
 
Reply With Quote
 
 
 
 
Dale King
Guest
Posts: n/a
 
      08-22-2003
"Thomas G. Marshall" <(E-Mail Removed). com>
wrote in message news:b6q0b.9284$(E-Mail Removed)...
> Roedy Green <(E-Mail Removed)> horrified us with:
>
> > On Mon, 18 Aug 2003 18:19:34 GMT, "Thomas G. Marshall"
> > <(E-Mail Removed). com> wrote or quoted
> >>

> >
> >> I too believe that the visual grouping is important, and as such I
> >> come to the opposite conclusion.

> >
> > The problem is consistency. If you are used to one convention the hit
> > the other sporadically, you may misread it.

>
> Consistency, as you put it, can obfuscate if it means that you must add
> control structures where non are needed.
>
> >
> > My solution is the SCID where such presentations are dynamically
> > generated and keyed to the viewer. The source code HAS no preferred
> > representation. It is just a list of nodes.

>
> Yep. There is a very fundamental concept here. There has always been a
> notion through the years that source code need not be latched to ascii
> characters droning on and on. This notion does not necessarily require

that
> the code is stored in database form. It just means that the presentation
> ability is gussed up.
>
> There have been many times I've wanted to edit my code just like a word
> document. I've wanted to make something highlight. I've wanted to

actually
> (!) drop in a small image in a gui app to explain what a particular
> algorithm is actually doing. I've thought that it would be neat to drop

in
> a UML (hierarchy only) diagram not in ascii-art. etc.


You can do that right now. Not to be seen in the text view of the source
code, but you can certainly do it in the JavaDocs. It would be really cool
if an IDE actually parsed the javadocs and provided you a real view of the
HTML within the editor itself.
--
Dale King


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
warning: missing braces around initializer Pawel C++ 13 11-14-2008 12:08 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
allowing braces around suites Kjetil Torgrim Homme Python 99 09-08-2004 06:13 AM
Re: allowing braces around suites Michael Sparks Python 1 08-31-2004 02:43 AM
RE: allowing braces around suites Delaney, Timothy C (Timothy) Python 2 08-30-2004 03:39 PM



Advertisments