if (isOkToDoStuff)
doStuff();
else
throw new Exception('unable to do stuff');
My logic was that the use of !s should be minimized, that the positive part naturally should come first, and that you should have the actual code for your function on top.
However, in recent times, I find myself liking another idiom better: handling exceptional and error cases first, and then doing what the function is supposed to do, like this:
if (!isOkToDoStuff)
throw new Exception('unable to do stuff');
if (!otherPrerequisiteINeed)
throw new Exception('unable to do stuff');
doStuff();
The advantage being no (ugly!) indentations or (unreadable!) &&-ed expressions for additional error conditions. Which will always creep up after the first deployment, or at least after the initial coding session.
Plus, no occasion to forget adding curly braces to the if clause. ;-)
The other, more important advantage, is that the idiom doesn't change over time. You always have the error conditions first, the code to ultimately run at the end, and the actual code is not buried under 16-indentation-weights forged out of nested ifs.
Somehow, it isn't as elegant. But more practical. Which, mostly, is to be preferred, whether we like it or not.
Agreed, I also put the error stuff at the front (it's just easier to understand I think, at least for me).
AntwortenLöschenThis got me thinking about static/dynamic typing again. Somehow, I have the impression that the debate is largely useless. It isn't really a "static vs. dynamic" issue.
LöschenSee how it relates to the topic at hand:
If I define a function
void foo(int bar) {
if (bar < qaux || bar > hoo)
throw new Exception(...);
}
then essentially, I am defining an operation on a new anonymous type with dynamic type-checking. It's like that mathematical notation that goes something like { i € N | i >= qaux, i <= hoo }.
And really, asking whether static type checking or dynamic is better, is asking the wrong question. It's all about readability and safety as it relates to one specific use case.
The question we should be asking is: Under what circumstances do I want an ad-hoc "type check" handcrafted in code, when do I want an anonymous type declared right in the function declaration (or somewhere near), and when do I want a real, fully declared class. And then the language that we use/choose should be designed to those needs.
Yeah, living in utopia again, I am. I'll send you a postcard. It's fun, and the food is quite to my liking.