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

Groups > comp.lang.java.programmer > #11343 > unrolled thread

Blocks for scope control

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 1 of 2  [1] 2  Next page →

#11343 — Blocks for scope control

See
http://stackoverflow.com/questions/1563030/anonymous-code-blocks-in-java
for a general discussion.

I'm talking specifically about the block by itself: a pair of braces by
themselves, enclosing some code in a method. On occasion I do run across
situations where a judicious use of such a block inside a method, to
restrict variable visibility, is handy.

I almost never see anyone else using these things this way. A block in a
method always seems to be associated with a control construct or
exception handling. As any number of references point out, you wouldn't
expect to see many usages of local blocks, mainly because 99 times out
of 100 that situation is probably handled best by a new method. But in
my years of looking at Java it occurs to me that I barely see any use of
this at all...even where it wouldn't be a bad idea.

Any thoughts?

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

[toc] | [next] | [standalone]

#11345

On 15.01.2012 16:50, Arved Sandstrom wrote:
> See
> http://stackoverflow.com/questions/1563030/anonymous-code-blocks-in-java
> for a general discussion.
>
> I'm talking specifically about the block by itself: a pair of braces by
> themselves, enclosing some code in a method. On occasion I do run across
> situations where a judicious use of such a block inside a method, to
> restrict variable visibility, is handy.
>
> I almost never see anyone else using these things this way. A block in a
> method always seems to be associated with a control construct or
> exception handling. As any number of references point out, you wouldn't
> expect to see many usages of local blocks, mainly because 99 times out
> of 100 that situation is probably handled best by a new method. But in
> my years of looking at Java it occurs to me that I barely see any use of
> this at all...even where it wouldn't be a bad idea.
>
> Any thoughts?

I can't remember ever having used a block without flow control inside a 
method for other purposes than experimenting with scoping rules.  And I 
am not missing anything.  I believe the fact that variables can be 
declared in a for loop header as well as that all loops and if-else open 
a new scope (as well as methods, of course) is responsible for me never 
using blocks inside methods.  IMHO chances are that if you need one or 
more blocks inside methods that these things are pretty independent and 
better handled by a method call which has the added benefit of providing 
documentation via the method name, if chosen wisely.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#11348

On 15.01.2012 17:18, Stefan Ram wrote:
> Arved Sandstrom<asandstrom3minus1@eastlink.ca>  writes:
>> Any thoughts?
>
>    Im using this whenever it makes sense. For example,
>    say you wanted to add a button:
>
> { final Button button = new Button(); frame.add( button ); }

Why do you think it makes sense to replace this

frame.add( new Button() );

with the block above?  If initialization is more complex, I'd rather do this

frame.add( createButton() );

than

>    or apply the refactor »extract method«:
>
> void m( final Frame frame )
> { final Button button = new Button(); frame.add( button ); }

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#11360

Stefan Ram wrote:
> Robert Klemm writes:
>>> { final Button button = new Button(); frame.add( button ); }
>> Why do you think it makes sense to replace this
>> frame.add( new Button() );
>> with the block above?
>
>    This code (comments removed by me):
>
> for (ThumbnailAction thumbAction : chunks) {
>      JButton thumbButton = new JButton(thumbAction);
>      buttonBar.add(thumbButton, buttonBar.getComponentCount() - 1);
> }
>
>    can be found in the renowned Java Tutorial at
>
> http://docs.oracle.com/javase/tutorial/uiswing/components/icon.html
>
>    . So such temporary names for one-time use are not
>    against common teachings.

Some argue, and there's merit in the position, that the one-time name idiom 
enhances code readability over the constructor-in-the-method-argument idiom.

(I also find merit in the "you ought to know Java well enough to read a 
friggin' construction in an argument, for God's sake" argument, for anyone 
claiming remuneration for their Java skills.  Lacking such knowledge and 
charging for your Java skills is fraud if the ignorance is not disclosed up 
front.)

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11373

On 15.01.2012 17:59, Stefan Ram wrote:
> Robert Klemme<shortcutter@googlemail.com>  writes:
>>> { final Button button = new Button(); frame.add( button ); }
>> Why do you think it makes sense to replace this
>> frame.add( new Button() );
>> with the block above?
>
>    This code (comments removed by me):
>
> for (ThumbnailAction thumbAction : chunks) {
>      JButton thumbButton = new JButton(thumbAction);
>      buttonBar.add(thumbButton, buttonBar.getComponentCount() - 1);
> }
>
>    can be found in the renowned Java Tutorial at
>
> http://docs.oracle.com/javase/tutorial/uiswing/components/icon.html
>
>    . So such temporary names for one-time use are not
>    against common teachings.

OK, but here there are more arguments to add() and the line is longer. 
That makes more sense than the original example to me.

Cheers

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#11353

On 1/15/2012 7:50 AM, Arved Sandstrom wrote:

> I almost never see anyone else using these things this way.


IMO, I dislike spurious and overused indentation in code, so that's 
likely why I shy away from "extra" use of braces.

   for( ...some code )
   {
      do some init
      {
          do a little work
          {
             declare a temporary variable
          }
          {
             declare another temporary variable
          }
          {
             declare yet another temporary variable
          }
          {
             declare still yet another temporary variable
             {
                 declare a temporary variable inside
                 an anonymous block
             }
          }
      }
   }

vs. just one level of indentation, I believe I'd greatly prefer the 
latter, especially in the long run.  And the above is with 3-4 spaces 
for indenting, imagine what it would look like with 8.

[toc] | [prev] | [next] | [standalone]

#11361

On 01/15/2012 09:57 AM, markspace wrote:
> On 1/15/2012 7:50 AM, Arved Sandstrom wrote:
>
>> I almost never see anyone else using these things this way.
>
>
> IMO, I dislike spurious and overused indentation in code, so that's likely why
> I shy away from "extra" use of braces.
>
> for( ...some code )
> {
>    do some init
>    {
>       do a little work
>       {
>          declare a temporary variable
>       }
>       {
>          declare another temporary variable
>       }
>       {
>          declare yet another temporary variable
>       }
>       {
>          declare still yet another temporary variable
>          {
>             declare a temporary variable inside
>             an anonymous block
>          }
>       }
>    }
> }
>
> vs. just one level of indentation, I believe I'd greatly prefer the latter,
> especially in the long run. And the above is with 3-4 spaces for indenting,
> imagine what it would look like with 8.

Since eight-space indentation violates the Java coding conventions it doesn't 
deserve consideration.  Code that indents eight spaces should be rejected in 
code review and brought into compliance.

<http://www.oracle.com/technetwork/java/codeconventions-136091.html#262>

But your larger point is valid, and you can just do this:

   for( ...some code )
   {
      do some init
      do a little work
      declare a temporary variable
      declare another temporary variable
      declare yet another temporary variable
      declare still yet another temporary variable
      declare a temporary variable inside
   }

The reason to go with the supposedly "extra" braces is to guarantee that a 
temporary variable is not re-used, but if a method is so long that that's a 
risk there's a good chance that it's too long.

And again I say, "anonymous block" makes no sense because blocks aren't named 
in the first place.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11359

  Arved Sandstrom wrote:
> See
> http://stackoverflow.com/questions/1563030/anonymous-code-blocks-in-java
> for a general discussion.
>
> I'm talking specifically about the block by itself: a pair of braces by
> themselves, enclosing some code in a method. On occasion I do run across
> situations where a judicious use of such a block inside a method, to
> restrict variable visibility, is handy.
>
> I almost never see anyone else using these things this way. A block in a
> method always seems to be associated with a control construct or
> exception handling. As any number of references point out, you wouldn't
> expect to see many usages of local blocks, mainly because 99 times out
> of 100 that situation is probably handled best by a new method. But in
> my years of looking at Java it occurs to me that I barely see any use of
> this at all...even where it wouldn't be a bad idea.
>
> Any thoughts?

You see it standardly in initialization blocks, especially static, though I 
often (more often than not) find myself refactoring static initialization 
blocks to private static methods.  For instance initialization they're 
extremely useful for blocks that multiple constructors must share.

Within methods I use them as well, to enforce temporariness of variables. 
This is very handy to prevent re-use of a variable whose usefulness has 
expired.  The need is rare, but like the legendary left-handed stembolt, if 
you don't have it when you need it, that's a worry.

This idiom is also valid in other languages (e.g., C).

Calling such code blocks "anonymous" doesn't make sense.  Code blocks aren't 
named in the first place.

There are many, many idioms in Java that are woefully underused.  'assert' is 
the prime example.  People don't understand it, even excoriate it (strange as 
that seems), and it's been around about a decade, since Java 1.4.  Lack of use 
does not equate to lack of value.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11366

On 12-01-15 03:00 PM, Lew wrote:
>  Arved Sandstrom wrote:
>> See
>> http://stackoverflow.com/questions/1563030/anonymous-code-blocks-in-java
>> for a general discussion.
>>
>> I'm talking specifically about the block by itself: a pair of braces by
>> themselves, enclosing some code in a method. On occasion I do run across
>> situations where a judicious use of such a block inside a method, to
>> restrict variable visibility, is handy.
>>
>> I almost never see anyone else using these things this way. A block in a
>> method always seems to be associated with a control construct or
>> exception handling. As any number of references point out, you wouldn't
>> expect to see many usages of local blocks, mainly because 99 times out
>> of 100 that situation is probably handled best by a new method. But in
>> my years of looking at Java it occurs to me that I barely see any use of
>> this at all...even where it wouldn't be a bad idea.
>>
>> Any thoughts?
> 
> You see it standardly in initialization blocks, especially static,
> though I often (more often than not) find myself refactoring static
> initialization blocks to private static methods.  For instance
> initialization they're extremely useful for blocks that multiple
> constructors must share.

At the instance and class levels, it's true, these blocks operate
similarly to "local" blocks.

> Within methods I use them as well, to enforce temporariness of
> variables. This is very handy to prevent re-use of a variable whose
> usefulness has expired.  The need is rare, but like the legendary
> left-handed stembolt, if you don't have it when you need it, that's a
> worry.

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.

> This idiom is also valid in other languages (e.g., C).
> 
> Calling such code blocks "anonymous" doesn't make sense.  Code blocks
> aren't named in the first place.

Well, to be fair, *I* didn't call them "anonymous", the original poster
at StackOverflow did. :-) Strictly speaking they are blocks, and nothing
but blocks; in order to specify more exactly what type of block I meant
I referred to them as "local blocks".

> There are many, many idioms in Java that are woefully underused. 
> 'assert' is the prime example.  People don't understand it, even
> excoriate it (strange as that seems), and it's been around about a
> decade, since Java 1.4.  Lack of use does not equate to lack of value.
> 
Quite apart from (lack of) understanding as to how to apply assertions
effectively and correctly, I believe that there are other reasons why
they are not more widely used. Some are good, some not so good, some are
neutral.

I'm with you on this one, though. I like assertions and use them.

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

[toc] | [prev] | [next] | [standalone]

#11369

Arved Sandstrom wrote:
> Lew wrote:
>> There are many, many idioms in Java that are woefully underused.

Okay, not all that many, but some.

>> 'assert' is the prime example.  People don't understand it, even
>> excoriate it (strange as that seems), and it's been around about a
>> decade, since Java 1.4.  Lack of use does not equate to lack of value.
>>
> Quite apart from (lack of) understanding as to how to apply assertions
> effectively and correctly, I believe that there are other reasons why
> they are not more widely used. Some are good, some not so good, some are
> neutral.
>
> I'm with you on this one, though. I like assertions and use them.

I am curious as to the "good" reasons why they're not more widely used. I can 
think of none I'd categorize as "good".

There are good reasons not to use them in certain scenarios, e.g., they are 
not intended nor should be used for checking arguments to public methods, but 
that doesn't speak to why 'assert' isn't more widely used for the intended use 
cases.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11512

On 12-01-15 07:45 PM, Lew wrote:
> Arved Sandstrom wrote:
>> Lew wrote:
>>> There are many, many idioms in Java that are woefully underused.
> 
> Okay, not all that many, but some.
> 
>>> 'assert' is the prime example.  People don't understand it, even
>>> excoriate it (strange as that seems), and it's been around about a
>>> decade, since Java 1.4.  Lack of use does not equate to lack of value.
>>>
>> Quite apart from (lack of) understanding as to how to apply assertions
>> effectively and correctly, I believe that there are other reasons why
>> they are not more widely used. Some are good, some not so good, some are
>> neutral.
>>
>> I'm with you on this one, though. I like assertions and use them.
> 
> I am curious as to the "good" reasons why they're not more widely used.
> I can think of none I'd categorize as "good".
> 
> There are good reasons not to use them in certain scenarios, e.g., they
> are not intended nor should be used for checking arguments to public
> methods, but that doesn't speak to why 'assert' isn't more widely used
> for the intended use cases.
> 
Lew, I had side-effects of assertions in mind when I wrote that, for
one. I know, and you know, that Java docs on assertions clearly point
out that assertions should not have side-effects, that you should be
able to omit their execution and not affect the remaining code. However,
good intentions and all, a widespread use of assertions by developers
who haven't thoroughly checked the assertion logic to ensure its purity
may lead to testing anomalies.

As an example, what if the condition you wish to assert at a specific
point has no immediately available variables to work with? It might be a
temptation for a programmer to call some getters to obtain the values.
As we know, many getters are not side-effect free, even ones that ought
to be, and unless a coder religiously checks this out there may be a
problem. A novice coder might not notice that a getter is synchronized,
as an example, and simply note the fact that the getter itself does
nothing but return a value.

Perhaps not a "good" reason, but I'd call it a realistic one.

Yes, the Java assertion documentation happens to use an example where a
local variable is conveniently produced by a previous necessary piece of
logic, and the following assertion can happily use that value. Not
always so easy.

Another decent reason, in my opinion, is if the management of them is
not disciplined. An organization that doesn't even wonder whether they
are disciplined enough to manage assertions in code isn't, and others
that do ask the question may decide that they are not.

What I mean by this is, assertions are easy to put in. They are not
always correct when put in, and they have to be maintained in any case
as code changes (or at least removed if necessary). Existing obsolete
assertions need to be taken into account when adding new ones in the
same class or package, because if you enable one then you may enable
more. Or you remove old ones you don't understand, if you trust yourself
to understand the business rules from 4 years ago well enough to
classify the assertions as being defunct.

Let me put it this way: I would feel good about looking at code that had
assertions in it if I saw that they were also commented where necessary,
including traceability notes where that makes sense, *and* were
supported by unit tests that exercised the assertions.

Again, you may wish to not think of this as a "good" reason. It's not
really. It's another realistic reason. I've worked with a number of
development teams that, if they were ever to read about assertions and
get a wild hair about trying them, would either be useless with them or
be obstructive with them. It may not be a "good" thing that they don't
use assertions, but it's not a bad thing either.

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

[toc] | [prev] | [next] | [standalone]

#11516

On 20.01.2012 02:54, Arved Sandstrom wrote:
> Another decent reason, in my opinion, is if the management of them is
> not disciplined. An organization that doesn't even wonder whether they
> are disciplined enough to manage assertions in code isn't, and others
> that do ask the question may decide that they are not.

I think this does not necessarily need to be handled on organization 
level.  Why make it so big?  Every developer can help himself and their 
colleagues by using them in a reasonable way.

> What I mean by this is, assertions are easy to put in. They are not
> always correct when put in, and they have to be maintained in any case
> as code changes (or at least removed if necessary). Existing obsolete
> assertions need to be taken into account when adding new ones in the
> same class or package, because if you enable one then you may enable
> more. Or you remove old ones you don't understand, if you trust yourself
> to understand the business rules from 4 years ago well enough to
> classify the assertions as being defunct.

Assertions also have the effect that they force you to think about 
certain - possibly not obvious - properties of the code / class at hand 
when you change the code.  So while an assertion may look tricky it 
actually helps you when modifying code to not forget important aspects. 
  This may be more tedious but it certainly helps code robustness in the 
long run.

> Let me put it this way: I would feel good about looking at code that had
> assertions in it if I saw that they were also commented where necessary,
> including traceability notes where that makes sense, *and* were
> supported by unit tests that exercised the assertions.

I view assertions in part also as documentation.  Often no additional 
commenting is needed.  I frequently have a private boolean method 
"classInvariant" or with other (hopefully telling) name with checks and 
has documentation of its own.  In these cases you have the name of the 
method plus documentation on the method.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#11538

On 01/20/2012 12:07 PM, Stefan Ram wrote:
> Robert Klemme<shortcutter@googlemail.com>  writes:
>> commenting is needed.  I frequently have a private boolean method
>> "classInvariant" or with other (hopefully telling) name with checks and
>
> private static boolean  classInvariant(){ ... }
> private        boolean objectInvariant(){ ... }
>
>    However, since it's boolean, I prefer »is«- or »has«-names:
>
> boolean isValid(){ ... }
>
>    . One can compare the readability of:
>
> if( this.classInvariant() )...
>
>    and
>
> if( this.isValid() )...
>
>    .

There is rarely, if ever, a good reason to qualify a method name with 'this.' 
  It does not affect the semantics of the statement, and as documentation is 
misleading.

The canonical mechanism to prove invariants is the 'assert' statement.  It is 
a compiler- and runtime-enforced program comment.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11539

On 12-01-20 03:41 AM, Robert Klemme wrote:
> On 20.01.2012 02:54, Arved Sandstrom wrote:
>> Another decent reason, in my opinion, is if the management of them is
>> not disciplined. An organization that doesn't even wonder whether they
>> are disciplined enough to manage assertions in code isn't, and others
>> that do ask the question may decide that they are not.
> 
> I think this does not necessarily need to be handled on organization
> level.  Why make it so big?  Every developer can help himself and their
> colleagues by using them in a reasonable way.

When I say "organization" I don't mean company necessarily. I really
mean team or developer group. Although for a very small company it'll
end up being the same thing.

There are obviously differing opinions here, but I don't myself think
that the use of assertions is something you want to leave up to
individual developers. The fact that they are being used, and the
initial decision to use them, ought to be discussed and coordinated and
communicated across the project team.

>> What I mean by this is, assertions are easy to put in. They are not
>> always correct when put in, and they have to be maintained in any case
>> as code changes (or at least removed if necessary). Existing obsolete
>> assertions need to be taken into account when adding new ones in the
>> same class or package, because if you enable one then you may enable
>> more. Or you remove old ones you don't understand, if you trust yourself
>> to understand the business rules from 4 years ago well enough to
>> classify the assertions as being defunct.
> 
> Assertions also have the effect that they force you to think about
> certain - possibly not obvious - properties of the code / class at hand
> when you change the code.  So while an assertion may look tricky it
> actually helps you when modifying code to not forget important aspects.
>  This may be more tedious but it certainly helps code robustness in the
> long run.
> 
>> Let me put it this way: I would feel good about looking at code that had
>> assertions in it if I saw that they were also commented where necessary,
>> including traceability notes where that makes sense, *and* were
>> supported by unit tests that exercised the assertions.
> 
> I view assertions in part also as documentation.  Often no additional
> commenting is needed.  I frequently have a private boolean method
> "classInvariant" or with other (hopefully telling) name with checks and
> has documentation of its own.  In these cases you have the name of the
> method plus documentation on the method.
> 
> Kind regards
> 
>     robert
> 
I also view assertions as documentation. I consider them important
enough in this role that I dislike casual and/or trivial use of
assertions, because pointless assertions can obscure the role of
genuinely important ones. Another reason why I think there ought to be
some team guidelines on these things.

AHS

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

[toc] | [prev] | [next] | [standalone]

#11540

Arved Sandstrom wrote:
> Robert Klemme wrote:
>> Arved Sandstrom wrote:
>>> ... [snip] ...
> There are obviously differing opinions here, but I don't myself think
> that the use of assertions is something you want to leave up to
> individual developers. The fact that they are being used, and the
> initial decision to use them, ought to be discussed and coordinated and
> communicated across the project team.

+1 not least because of the endemic ignorance and superstition around 
'assert'. A team discussion and documentation can elucidate the sound 
engineering principles behind when to use and not use the idiom.

>>> What I mean by this is, assertions are easy to put in. They are not
>>> always correct when put in, and they have to be maintained in any case
>>> as code changes (or at least removed if necessary). Existing obsolete
>>> assertions need to be taken into account when adding new ones in the
>>> same class or package, because if you enable one then you may enable
>>> more. Or you remove old ones you don't understand, if you trust yourself
>>> to understand the business rules from 4 years ago well enough to
>>> classify the assertions as being defunct.

Assertions are about algorithmic invariants. Being invariant, they shouldn't 
change, and then only when such fundamental algorithmic changes are underway 
that a responsible organization would carefully document them anyway.

The effort to place assertions correctly is closely tied to the effort to 
understand the algorithm properly.

>> Assertions also have the effect that they force you to think about
>> certain - possibly not obvious - properties of the code / class at hand
>> when you change the code.  So while an assertion may look tricky it
>> actually helps you when modifying code to not forget important aspects.
>>   This may be more tedious but it certainly helps code robustness in the
>> long run.
>>
>>> Let me put it this way: I would feel good about looking at code that had
>>> assertions in it if I saw that they were also commented where necessary,
>>> including traceability notes where that makes sense, *and* were
>>> supported by unit tests that exercised the assertions.
>>
>> I view assertions in part also as documentation.  Often no additional
>> commenting is needed.  I frequently have a private boolean method
>> "classInvariant" or with other (hopefully telling) name with checks and
>> has documentation of its own.  In these cases you have the name of the
>> method plus documentation on the method.
>>
> I also view assertions as documentation. I consider them important
> enough in this role that I dislike casual and/or trivial use of
> assertions, because pointless assertions can obscure the role of
> genuinely important ones. Another reason why I think there ought to be
> some team guidelines on these things.

Of course, those guidelines should encapsulate the extant documentation and 
articles on their correct use. It is fairly objective to evaluate whether 
'assert' is used correctly. I agree with your recommendation, but it's 
predicated on the guidelines avoiding stupidity.  For example, it is never 
correct to use 'assert' in lieu of a conventional check, say an 'if' 
structure, for non-nullity of arguments to a public method.

I say this because some teams where I've worked believe that best practices 
are a matter of seniority or democracy. But some pretty senior team members 
I've met could have observed their own polyps directly given how far their 
crania were up their viscera, and truth is not amenable to voting.

Colorful rhetoric aside, I'm simply saying that team guidelines are a good 
idea to the degree that they're correct, and that correctness is discernible 
in a discussion of 'assert' practices.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11372

On 15.01.2012 22:49, Arved Sandstrom wrote:
> On 12-01-15 03:00 PM, Lew wrote:
>>   Arved Sandstrom wrote:
>> You see it standardly in initialization blocks, especially static,
>> though I often (more often than not) find myself refactoring static
>> initialization blocks to private static methods.  For instance
>> initialization they're extremely useful for blocks that multiple
>> constructors must share.
>
> At the instance and class levels, it's true, these blocks operate
> similarly to "local" blocks.

That's also a feature I use from time to time.  But I thought this 
discussion was more about blocks inside methods since initializer blocks 
are a quite different beast (you can view them as anonymous methods 
without arguments and return type).

>> Within methods I use them as well, to enforce temporariness of
>> variables. This is very handy to prevent re-use of a variable whose
>> usefulness has expired.  The need is rare, but like the legendary
>> left-handed stembolt, if you don't have it when you need it, that's a
>> worry.
>
> 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.

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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#11511

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

[toc] | [prev] | [next] | [standalone]

#11564

On 20.01.2012 02:16, Arved Sandstrom wrote:
> On 12-01-16 02:55 AM, Robert Klemme wrote:
>> On 15.01.2012 22:49, Arved Sandstrom wrote:
> [ SNIP ]
>
>> 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.

> 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.

Why _one_ method?  There could be a method for each variant, couldn't 
it?  Chances are that the same code could be used for several items so 
you end up with less methods than items.

> 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.

I agree that this boilerplate is tedious, regardless how you do it.  But 
I didn't guess that your description was about such a scenario. ;-)

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

You're welcome!

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#11566

On 12-01-21 08:25 AM, Robert Klemme wrote:
> On 20.01.2012 02:16, Arved Sandstrom wrote:
>> On 12-01-16 02:55 AM, Robert Klemme wrote:
>>> On 15.01.2012 22:49, Arved Sandstrom wrote:
>> [ SNIP ]
>>
>>> 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.
> 
>> 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.
> 
> Why _one_ method?  There could be a method for each variant, couldn't
> it?  Chances are that the same code could be used for several items so
> you end up with less methods than items.

There could be, sure. I'll discuss that below your second comment.

>> 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.
> 
> I agree that this boilerplate is tedious, regardless how you do it.  But
> I didn't guess that your description was about such a scenario. ;-)
[ SNIP ]

There are a number of Java command line option parsers available; I
happen to like JArgs which is GNU getopt compatible.

Your first step after defining your options and running the parser on
actual arguments is to retrieve raw option values. JArgs is not generic,
so the retrieved option values are retrieved as Objects although they
are actually Strings or Booleans or Doubles or Integers or Longs.
Depending on how many of these types are in use in your situation, if
you were going to have convenience methods at all you'd have one for
each datatype involved in your options.

Many or some of your convenience methods might accept an option default
parameter, to be passed on to the appropriate JArgs getOption method.
This shouldn't multiply the number of methods that you've created.

I'm not going to deliberately complicate things so as to scupper your
argument, but in the case of the processing I was doing at this stage,
some of the String option values could only have certain values (they
referred to input and output formats, actually). I have enums defined
for this purpose, so for some of the String options the retrieved values
were immediately converted to enum instances. Other Strings were
freeform so no such processing was appropriate.

That's another method right there, at a minimum. Let us say one extra.

Similarly, a couple of the String options represented file names. Rather
than set them as generic Strings into my own "command line options"
object, I wanted them to be Files. Null is not an acceptable value for
the java.io.File ctor, so at the very least I had to look for null for
_these_ particular String options; "" is OK for java.io.File but it's
not OK for my app.

Hence a bit of specialized "String options meant to be filenames"
processing for some options.

This would/could be an extra convenience method of its own.

In summary, looking at my actual application command line options
(including which option datatypes I actually use), something like a
dozen of them [1], one could create half a dozen convenience methods
that would be used instead.

I don't think I can credibly argue that using the methods would be
worse. I am just not convinced it would be better. :-)

AHS

1. I think the number of options I have is justified. I probably could
have reasonably added a couple more. I've been using getopt and GNU
enhanced getopt and shell getopts for well over 20 years. When I first
encountered these beasts, after going through the usual exercise of
writing my own C.L. handling in C, I'll admit to having gone overboard.
But I'd like to think I am more sensible now: good command line design
is based on lots of usability experience with a dash of artistry.

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

[toc] | [prev] | [next] | [standalone]

#11577

On 21.01.2012 15:41, Arved Sandstrom wrote:
> On 12-01-21 08:25 AM, Robert Klemme wrote:
>> On 20.01.2012 02:16, Arved Sandstrom wrote:
>>> On 12-01-16 02:55 AM, Robert Klemme wrote:
>>>> On 15.01.2012 22:49, Arved Sandstrom wrote:

>> I agree that this boilerplate is tedious, regardless how you do it.  But
>> I didn't guess that your description was about such a scenario. ;-)

> In summary, looking at my actual application command line options
> (including which option datatypes I actually use), something like a
> dozen of them [1], one could create half a dozen convenience methods
> that would be used instead.
>
> I don't think I can credibly argue that using the methods would be
> worse. I am just not convinced it would be better. :-)

Fair enough.

> But I'd like to think I am more sensible now: good command line design
> is based on lots of usability experience with a dash of artistry.

I'd say this is true for so many areas of software engineering. :-)

Thank you for the elaborate explanation!

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web