Should asserts be disabled in production?

I used to be quite annoyed by Perl CPAN's

Carp::Assert: "assert(...) if DEBUG;"

i.e. by the fact that you have to append "if DEBUG" to an assertion in order to get it disabled in production.



Now, I have flipped.



I often want assertions enabled in production code. At least cheap assertions.  In fact, I might go so far as to say "assertions should be enabled in production code by default, unless you explicitly say not to".



In which case, the Perl Carp::Assert syntax is not totally unreasonable.



I might prefer the Pythonish



if DEBUG: assert(...)



so that you can see the "if DEBUG" right up front.



But then again, Python's assert is disabled when you run Python "optimized" via python -O.



I was somewhat flabbergasted when I encountered Python style guides that recommended not using asserts, or specifically not using asserts inside library functions.    (Can't find a reference right now, so perhaps this is rare advice.)



Reason: since Python assert is disabled when you run optimized -O (which is common in some worlds), and since libraries cannot be sure that somebody competent is calling them, libraries should do

if !valid(parameter): raise someException

rather than

assert valid(parameter)

This advice is accurate, but unfortunate.  I always prefer concise code, and "assert" is more concise than "if...raise".   And probably less fragile, since exception hierarchies have a habit of changing.





So I can't blame Python, but I can still regret it.

Principle of Smallest Scope

My mini-flame about a comment that might be interpreted as idiotically forbidding declaring a named subroutine inside a named subroutine inspired me to write this blurb about "The Principle of Smallest Scope".



I don't think I originated this principle, although I have practiced it for (ahem) decades, in (ahem) two different centuries. (ahem, probably scared off lots of headhunters: too old)



However, googling could not find me a reference for 'Principle of Smallest Scope'. Perhaps after I write this it will.  (Perhaps also I just misremembered the name - "Principle of Least Scope"? "Principle of Most Restricted Scope"?  If so, I will update this blog with a pointer to a better name.)



The Principle of Smallest Scope is much like the Law of Demeter, although that is more about object oriented design, whereas POSS applies to non-object systems.  Both are just particular forms of information hiding.



So, what do I mean by the 'Principle of Smallest Scope'?



I mean that definitions, both named and anonymous, should be restricted to the smallest reasonable scope.



E.g. it is bad to use a global variable when a procedure local variable is sufficient.



E.g. within a procedure, you may have temporary variables - e.g. small local common subexpression elimination.

...
ret := big_complex_function_returning_struct(...)
print ret.to_string()
assert( not ret.is_error() )
next_function( ret.field1, "do more stuff" )
...

if idioms like this are used over and over, then I think you should restrict the scope of ret, if your language permits it:

sub some_function () {
    ...
    {
        ret := big_complex_function_returning_struct(...)
        print ret.to_string()
        assert( not ret.is_error() )
        next_function( ret.field1, "do more stuff" )
    }
    ...
    {
        ret := another_big_complex_function_returning_struct(...)
        print ret.to_string()
        assert( not ret.is_error() )
        another_next_function( ret.fieldA, "different but similar" )
    }
    ...
}

rather than

sub some_function () {
    ...
    ret0 := big_complex_function_returning_struct(...)
    print ret0.to_string()
    assert( not ret0.is_error() )
    next_function( ret0.field1, "do more stuff" )
    ...
    ret1 := another_big_complex_function_returning_struct(...)
    print ret0.to_string()
    assert( not ret1.is_error() )
    another_next_function( ret0.fieldA, "different but similar" )
    ...
}

E.g. it is good for a programming language to support scopes that are smaller than function scope.

    Python fails this.



E.g. it is good to be allowed to declare named subroutines within named subroutines - and for it to be illegal to access the inner named subroutine outside of its enclosing scope.  (At least, illegal by default.)

    Perl fails this.



E.g. ditto nested classes.  Lexically nested whatevers.









Now, I admit: masking of names can be confusing.  It may be good to warn.   It may also be good to require explicit override.





More later...

 

Variable will not stay shared in subroutine

Variable will not stay shared in subroutine: "The correct solution is not to declare a named subroutine inside a named subroutine."
'via Blog this'

This sort of comment pisses me off.   Nesting and lexical scope are some of the most valuable concepts in programming language design.



Just as security has the Principle of Least Privilege, programs should usually take advantage of the Principle of Smallest Scope.



Temporary values should have the smallest scope possible.



Helper functions are just temporary values that happen to be code.  It should be possible to define lexically nested functions that are not visible outside the lexical scope.



Perhaps the author of the comment that pissed me off may have meant to be more specific: "Perl's implementation of 'nested subroutines' is misleading, and should not be used because of this possible confusion."



Not least because Perl's 'nested subroutines' are not really lexically nested.  Instead, they are (as poster Ovid earlier in the thread before the4 comment that pissed me off says):

[Named] subroutines are entries in the current namespace's symbol table (in a typeglob slot) and this does not allow for nesting. As the docs explain, this can be gotten around by using an anonymous subroutine because these get stuffed in a scratchpad, thus making them lexically scoped.

Also, it is quite confusing that 'nested name subroutines' and 'nested anonymous subroutines' have such different behavior.



It is also fair to say that this specificity may have been implied by context.  I should not get pissed off so easily.



But on the technical issue, yeah, Perl's funky support for not-really-lexically-nested-named-functions is a piss-off.



---



I think I am annoyed by this because recently I have writing Python to use pyobjc on my Apple MacBook  - and Python does not have lexical scopes apart from functions and modules.  So Python does not support the Principle of Smallest Scope.  At least up to Python3.  Perl mostly supports the Principle of Smallest Scope - except for stupidities like this not-really-lexically-nested-named-functions.