3 ms·
I think C does not make you write simpler code. It makes people take short-cuts. Static allocations, using a hand rolled linked list, skipping return value chec
by ahoka 11y ago
I think C does not make you write simpler code. It makes people take short-cuts. Static allocations, using a hand rolled linked list, skipping return value checks or boundary checks etc. are all typical to C programs.
- vardump 11y agoNot 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.