Chris V does compliance testing. This often means they trace through logic in code to ensure that very specific conditions about the code’s behavior and logic are met. This creates unusual situations, where they might have access to specific and relevant pieces of code, but not the entire codebase. If they spot something unusual, but not within the boundaries of their compliance tests, they just pass on by it.

One of the C++ code bases Chris had to go through featured this “defensive” pattern everywhere.

if (someConditionalStatement)  
{
    // do stuff  
}
else  
{
    runtime_assert(false && "some condition was not met");  
}
Chris doesn't have access to runtime_assert's definition. It *is* possible to `&&` a boolean and a string together- you get a boolean result, though. So the `"some condition was not met"` message just vanishes, as if it weren't there. Literally, this is just runtime_assert(false). Which, excepting the extraneous string, almost makes sense, if you want the failed condition to trigger some exception/error pathway. Then there were these variations on the pattern: 

if (someConditionalStatement)  
{
    // do stuff  
}
else  
{
    runtime_assert(someConditionalStatement);  
}

Which, again, essentially just means runtime_assert(false). And again, this almost makes sense. As Chris explains:

I mean, it works. It all works. It’s just a weird and unnecessary way to write it. …I get the feeling they have heard about error checking and defensive programming, but haven’t heard about exceptions and exception handling?

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!