Is there a good reason for choosing assert() over an if condition with an error?

18 views (last 30 days)
I want to make sure a condition is valid, so I write a quick test for it with a boolean output. Does it matter whether I put the test in an if/error block or an assertion? Is easier reading/fewer lines the only goal?
  12 Comments
Stephen23
Stephen23 on 5 May 2022
"favors the implicit branch unduly and penalizes the equivalent"
As it should: they are not equivalent.
"they're no more complex."
The IF is more complex by McCabe's definition, it is another path which can execute other code:
IF ohno
WHATEVER()
ERROR()
END
whereas this can never start another path:
ASSERT(~ohno)
Note that there is nothing in McCabe's definition that says that a path must execute code: this still adds one path:
IF blah
END
Nor does the definition provide a way to exclude paths that will never be executed (e.g. due to numeric/logical conditions), however you appear to want to optimize such things away... sadly McCabe did not deign to include a code optimizer in the definition of cyclomatic complexity. What happens in this case?:
IF ohno
HELLO()
end
% possibly nested down some function calls but with no extra paths:
function HELLO()
ERROR()
end
Given that MATLAB has a dynamic search path and scope, your concept essentially means that we cannot know the cyclomatic complexity of that code until runtime... or perhaps never, if HELLO() is pcode/compiled and ohno is false.
I much prefer the standard, simple, original/current McCabe definition which can be achieved using static code analysis of nothing more than the single function we wish to analzye. Which, incidentally, is what MLINT/CODECHECK does.
But I can see that we view this differently. Thank you for the interesting discussion!
dpb
dpb on 5 May 2022
But in the particular case they are equivalent -- while the if...end COULD could include more code, in this case it doesn't.
I don't argue that it would make computing a metric much more difficult, but imo one should recognize that one can have the same effective metric and the code is just as robust despite what the present metric may indicate as the one being higher than the other.
For a simple, short routine with only one or two exits, the numerical difference probably wouldn't show up much; a more involved routine with lots of error checking could really show up as a loser when, in fact, it really isn't.

Sign in to comment.

Accepted Answer

Stephen23
Stephen23 on 4 May 2022
Edited: Stephen23 on 4 May 2022
"Is easier reading/fewer lines the only goal?"
Why call two operators when you can call just one?
It certainly can make the intent clearer: ASSERT makes it clear that no other actions are intended/possible. In my quick internet search just now (not MATLAB specific), the general consensus seems to be that ASSERT should be used (much like its name implies) at particular points in code where certain condition/s must be met for the code to work. In contrast, an IF certainly implies that some other action might be performed at the programmers discretion.
My observation: ASSERT tends to be underused in MATLAB.
My recommendation: use whichever one makes your code look best and easier to read.
  1 Comment
dpb
dpb on 4 May 2022
Mayhaps it's just me and being an old dog, but I find I almost always have it backwards the first time for some reason...so almost always have to spend extra time debugging/fixing my logic when I try using it.
For legibility, I'll often use something like
if errortest(), error('Error msg'), end
instead of the full-blown indented if...end structure so it doesn't break up the code linear flow when scanning.

Sign in to comment.

More Answers (0)

Tags

Products

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!