[brown9-2]

I interpret this to mean two things:

1. If you are going to assert these things, don't do it in the middle of the method - do it in a place that makes sense (start of the method).

2. One of the members of my team likes to make assertions about parameters that aren't actually valid but just sound like they are, for example, wrapping the entire code in a method with an int id parameter with a

  if (id > 0) { 
     ...
  }

block so that the method silently does nothing if you pass in a negative number. Except of course that there's nothing in our domain model to say that IDs can't wrap zero into negative space or that this isn't a valid scenario.

So in other words, having a bunch of unnecessary assertions that spring up in seemingly random places makes your code hard to test.

[psnj]

> 1. If you are going to assert these things, don't do it in the middle of the method - do it in a place that makes sense (start of the method).

Sure, I can see that -- assertions in the middle of a method might well indicate that maybe that bit should be split into more than one method.

But the article goes further than that: they seem to complain about assertions guarding parameter values. I really don't get that. Actually, I'll go one further: complaining about that is unjustifiable.

Anyway, I also don't always get the particular flavour of OOP dogma that Java devs sometimes seem to promote. It certainly feels different to me from Python world, and I suppose it is.

When I see the phrase "silently does nothing" I feel vaguely uneasy.