3 ms·
Not sure why you've been voted down. I've seen too many lines of C and what you said is true most of the time. Although developers skipping return value checks
by vardump 11y ago
Not sure why you've been voted down. I've seen too many lines of C and what you said is true most of the time.
Although developers skipping return value checks is true in most languages.
- Gibbon1 11y agoI have two things to say. #1 The submitted article is very good. #2 I'd add to it, avoid pointer arithmetic when possible. Use array notation instead. Typically the difference in execution speed is zero to nil. #3 I'd really like a pragma that forces an exception for unchecked return values. Something like int DoSomeThing(/* whatever*/) #pragma exit "unchecked non_zero" Meaning if DoSomething() doesn't return zero the program bails.
- unscaled 11y ago> Although developers skipping return value checks is true in most languages. Yes, which is why I disagree with Go's approach for error codes as return values. I'm not saying that exceptions are the right solution everywhere, but if you return a error code, you should make it pretty hard to ignore it. In languages with Algebraic Data Types it's very easy to use Maybe or a Error(code) | Success(result) type. You've then got to explicitly deconstruct that type to get the result, so it's a bit harder to just forget handling the error.