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


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

Re: Blocks for scope control

From Lew <noone@lewscanon.com>
Newsgroups comp.lang.java.programmer
Subject Re: Blocks for scope control
Date 2012-01-20 15:54 -0800
Organization albasani.net
Message-ID <jfcur3$1nt$1@news.albasani.net> (permalink)
References (2 earlier) <IRHQq.2650$2C.1194@newsfe20.iad> <jevoes$qru$1@news.albasani.net> <2P3Sq.1782$lS6.832@newsfe20.iad> <9nsk4fFganU1@mid.individual.net> <yOmSq.1261$uh2.321@newsfe07.iad>

Show all headers | View raw


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

Back to comp.lang.java.programmer | Previous | NextPrevious 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