Safety vs Efficiency

Started by
30 comments, last by Ravyne 8 years, 8 months ago

I recommend to rethink this. I do quite some interviewing these days and saying something like this in an phone screen or interview would be a dark red flag. I don't know what experience you have in professional development, but maybe don't think so much shipping, but daily development in large teams of maybe 100 people. If you crash loud and hard on every little bug because of not programming defensively I don't see such a team working effectively.

A dark red flag? That's like saying you wouldn't hire someone because they use different code style than you, you can't just ask them to follow your company's style instead? To me it just sounds more like you're taking people's style decisions personally, and refusing to hire anyone that doesn't think the same way as you. That's a big red flag to me as anyone that would want to work there. You're trying to say infinitevly that crashing is bad style, but it isn't.

There are two ends to this point, one is to avoid crashing at all costs. This introduces bugs frequently, it keeps them around longer, possibly forever, it flat out lowers the quality of the software. On the other end we have crashing all the time, it gets the most bugs fixed but scares people more because in theory it might crash at an inopportune time and embarass people or cause frustration.

To me that says a very simple thing: it depends. It depends on the environment, the type of software, and who is working on it. If I'm working on my own game by myself i'm probably more likely to just make everything explode if it fails, that helps me find bugs fast, and I lose nothing from it crashing. In a big team environment it depends on what you're making, a tool crashing is more annoying than a game crashing. A game crashing is only bad really infront of customers. There isn't a one size fits all solution here.
Advertisement


2) Change the arguments to "void*" and "const void*", respectively; indicating that the arguments are not checked, since that is the caller's responsibility.

There are probably better options than voit * and const void *.

One method would be to duplicate the classes by deriving from the original but with a new name (and making no interface changes) which indicates the changes in responsibilities -- for example, a callee passed a Variant would be resonsible for validation checks, but a callee passed a CheckedVariant would not, safe in the knowlege that it was the callers responsibility.

If you want to get a bit fancy, you can structure things such that you can only get a CheckedVariant through a method on a nominal Variant, and enforce checking through that method (you might have different flavors of CheckedVariant as a result) if your checks are regular (as opposed to ad-hoc). You might further extend this through the CheckedVariant constructor or a conversion operator so that this can happen transparently at the callsite of methods taking CheckedVariants. You can further sprinkle in appropriate use of copy/move constructors and assignment operators to express the lifetime patterns that are appropriate.

That would reduce noise in the code and help spare your own human efficiency, but it also centralizes checking so that you can easily swap in asserts or what-have-you. When you detect that a conversion is not possible, all the advice above about failing immediately and loudly applies.

throw table_exception("(? ???)? ? ???");

This topic is closed to new replies.

Advertisement