Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11511

Re: Blocks for scope control

Show all headers | View raw

On 12-01-16 02:55 AM, Robert Klemme wrote:
> On 15.01.2012 22:49, Arved Sandstrom wrote:
[ SNIP ]

>> This is exactly the use I was calling out. After visibility modifiers we
>> then have a number of levels of scope - class, instance, method and
>> block. We already use restrictive variable scoping in blocks; everyone
>> who re-uses for-loop index names benefits from this.
>>
>> My point is simply that on some occasions, as you point out yourself,
>> you do want to "enforce temporariness" of a variable in a scope narrower
>> than that of its enclosing method. The answer here, on those infrequent
>> occasions where it makes sense to use a block, is not to blindly create
>> a new method simply to get variable scoping. That reflexive practice can
>> lead to unreadable fragmented code.
> 
> But there are other blocks which also restrict scope (i.e. flow
> control).  So more often than not I find myself using those.  Plus, I
> now have made it a habit to make variables final as often as possible
> (mostly for documentation reasons) and thusly also prevent accidental
> reuse.

Also a good practice. There is some irony in you mentioning this,
insofar as most programmers don't do this either...usually because they
don't see anyone else doing it. Which leads to a situation where one
needs to justify using "final" as often as possible, rather than the
burden of justification being the other way around.

I know there's the perennial debate about final classes, but final
variables are a different ball of wax. I rather wish folks thought the
way you did, and maybe then a coder would have to justify *not* making a
variable final.

> Regarding the method refactoring argument: if there is so much code and
> hence so many local variables that you want to use blocks to introduce
> smaller scopes chances are that the logic within that blocks is also
> largely independent from the code around so it is a good candidate for
> refactoring anyway.  The reason for refactoring into methods isn't the
> scope but the independent logic.
> 
> Kind regards
> 
>     robert
> 
To focus on your points above, you _would_ refactor into
methods...*except* for those few cases where the methods end up being
trivial, and because the method body is located elsewhere you lose some
perspective on your code, and the replacement of the potential local
blocks with methods obscures the calling code.

Let me give you an example. Some days prior to writing my post I had to
write some code that processed a number of items in a similar fashion.
Each item was a matter of 2 or 3 lines of code. In theory each process
could have been collapsed into one very long line with multiple
duplicated and chained method calls, rather than use temporary local
variables, but I abhor this practice. So for clarity I kept the
operations on each item as 2 or 3 lines of code with at least one
temporary local variable.

Although the type of the local variable was the same, the operations
that produced it were not - they depended on the item. So any method
that would have replaced all these individually simple simple groups of
operations would have been either a moderately complex switch or a
moderately complex if-else if-else structure, less easy to understand,
and more error-prone. Furthermore, a flag would have been necessary to
the method to indicate which branch to take.

As you may have guessed this logic had to do with post-processing
various String and Boolean command-line options delivered by a
command-line processor. Quite frankly there is nothing pretty about
this, and there never has been in any language I've ever used - all you
can hope for is to keep the code clear, as error-free as possible, as
change-proof as possible (one of the main reasons for me using local
blocks actually), and just tolerate the boilerplate processing otherwise.

So this is one example, and I think a decent one. I don't think I
actually need to defend it, because a block is a legitimate language
construct, and you may wish to use them sometimes rather than end up
with mini-methods.

However, the intent of the thread was to get some feedback, and I thank
you all for it.

AHS
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-15 11:50 -0400
  Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-15 17:10 +0100
  Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-15 17:32 +0100
    Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:21 -0800
    Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-16 07:59 +0100
  Re: Blocks for scope control markspace <-@.> - 2012-01-15 09:57 -0800
    Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:28 -0800
  Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:00 -0800
    Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-15 17:49 -0400
      Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 15:45 -0800
        Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-19 21:54 -0400
          Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-20 08:41 +0100
            Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 15:24 -0800
            Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-20 19:30 -0400
              Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 15:54 -0800
      Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-16 07:55 +0100
        Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-19 21:16 -0400
          Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-21 13:25 +0100
            Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-21 10:41 -0400
              Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-22 13:03 +0100
  Re: Blocks for scope control Roedy Green <see_website@mindprod.com.invalid> - 2012-01-16 06:09 -0800
    Re: Blocks for scope control Henk van Voorthuijsen <voorth@xs4all.nl> - 2012-01-16 07:03 -0800
  Re: Blocks for scope control Arne Vajhøj <arne@vajhoej.dk> - 2012-01-17 18:43 -0500
  Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 11:05 -0800
  Re: Blocks for scope control Gene Wirchenko <genew@ocis.net> - 2012-01-20 12:11 -0800
  Re: Blocks for scope control Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 21:24 -0500

csiph-web