4 ms·
>if you're gonna punt, early-return. I don't know what it is but I once interviewed for an embedded C position. During the interview, I wrote out some code sam
by esaym 7y ago
>if you're gonna punt, early-return.
I don't know what it is but I once interviewed for an embedded C position. During the interview, I wrote out some code samples. The only issue the interviewer found was that I had "returned early". He said there could basically only be one return in a function and it had to be at the end. I told him I'd never heard of that. He only said it was a "standard" that had to be followed because of the crypo involved in the code base.
Sadly, even though I didn't get the job, that stupid statement of only one return call in a function has stuck with me and lead to many mental arguments.
- riquito 7y agoStriving for a single return (without going out of your way to achieve it) is good practice. There are two main advantages: - it's obvious when the function ends, no hidden early exits in the middle of nowhere - if you need to do something before returning, there is only one place to do it (e.g. trim the output, e.g. log performances), and it make it easier to move this kind of last mile logic to a different function (if it's of any interest) About your interview, don't sweat it, is not for that you didn't pass (you could do a great job and yet lose to a more fit candidate)
- kqr 7y agoThe "standard" this might have been a reference to is MISRA C. It can be a useful rule to avoid leaking resources/finalising shit.