The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I like single exit points... That code would drive me nuts too...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
If the function is something easy... just one return at the end.
If the function is something normal size... what you said.
If the function is big... I do a second function to "check all needed stuff" at the beginning
and then what you said.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
I take a similar approach but I don't limit myself to just one return there. I let each sanity check have its own return statement because I find easier to deal with when debugging. Following the input sanitization I try to not have any returns unless a value is returned and then only at the bottom.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
It all depends on which measuring stick is used...
- # exits in a function
- # lines of code
- # lines of comments
- # paths in the code
- maintainability, modifiability
- only use positive condition tests (! using ! and certainly ! !!)
And of course if you (think you) are paid by lines of code produced there are many other "solutions"
I've been writing a little graphics library for C++ capable IoT devices.
The first thing I wanted to do was make JPEG loading work. I did that. I can't load JPEGs into memory all at once on such a little device so it required me to implement my own stream classes because std::iostream is too bloated and way to hard to implement over a simple memory buffer, even if it wasn't bloated because of the templates. On PCs I don't mind, but on these IoT things how much space your code takes up matters, and not just in RAM. So the JPEGs required a stream library.
In terms of getting things onto the displays, there is no unified driver or hardware interface for any display adapters, so now my graphics library requires a tiny interface a bit like DirectDraw.
And because device i/o is slow, it would be impossible to do anything without being able to exploit any asynchronous DMA capabilities of the hardware available, so *now* my library requires abstract interfaces to provide an asynchronous graphics operations model
All this elephanting code. And that's before I even start writing actual drivers for say an ILI9341 or an RA8875 LCD hardware controller.
Heck that's before I even start implementing basic things like line drawing and filling, or heaven forbid, fonts.
I love coding for these little things because you're so close to the metal, but when you want to go your own way with something, because existing offerings are too heavy or limited, you have to start over from scratch.