|
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
|
|
|
|
|
Bonus points to JSOP!
I actually like having two exit points at most
1st at the very top if your initial sanity checks on input parameters fail. Get that out of the qay early
2nd at the very end of the routine.
cheers
Chris Maunder
|
|
|
|
|
That's what I like too.
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.
M.D.V. 
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?"
|
|
|
|
|
Rick York wrote: I let each sanity check have its own return statement
Full disclosure: I do the same if it makes it cumbersome / ugly otherwise. But one test/return section at the top.
cheers
Chris Maunder
|
|
|
|
|
No religion in the lounge! 
|
|
|
|
|
hehe 
modified 5-Apr-21 21:01pm.
|
|
|
|
|
It all depends on which measuring stick is used...
- # exits in a function
- # lines of code
- # lines of comments
- # paths in the code
- readability,
- 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"
|
|
|
|
|
Visual Studio would show you that the else branch in unnecessary.
|
|
|
|
|
Hmm, to trying to please people who want a single exit point and clear intent when processing is completed:
if (condition)
{
goto returnStatement;
}
:returnStatement
return;
 
|
|
|
|
|
That's so, so wrong on so many levels...
cheers
Chris Maunder
|
|
|
|
|
My career best:
function doNothing(something) {
return something;
}
Nothing succeeds like a budgie without teeth.
|
|
|
|
|
Just to annoy everyone
switch (condition)
{
case true: return;
default:
}
|
|
|
|
|
if(the_code_below_can_not_be_executed) return;
|
|
|
|
|
Looks like a copy/paste error where the code wasn't cleaned up after the paste.
|
|
|
|
|
Of course! It should be:
if (!condition) {
}
|
|
|
|
|
// need to do something if conditions are right otherwise don't
if( condition )
{
do something
}
return
|
|
|
|
|
Agreed.
I like to avoid (complex) negative conditions; so I might have:
if ( negative condition as a positive) {
else {
return;
}
(Don't like your braces tho ... bad Feng Shui)
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
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.
*headdesk*
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.
Real programmers use butterflies
|
|
|
|
|
But you have the knowledge of what's required - you know you'll do it eventually so you might as well get on with it 
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
Well, if you want a really graphic description then you may have to use some rather graphic langua . . . oops - that's not what you meant.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I've always liked doing that. 
What I don't like is programming in a straight-jacket, as you seem to be. I work with CUDA these days and it definitely has its limitations but not nearly as severe as your little things do. My limitations are things like, I only have 8GB of VRAM and 2304 cores to work with - how am I ever going to make it fit? Luckily, my answer is buy a better card if we have to. You don't seem to have that option available, unfortunately.
"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?"
|
|
|
|
|
Coding with no RAM builds character!
Real programmers use butterflies
|
|
|
|
|
Yes, but it's a bit too masochistic for my tastes.
"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?"
|
|
|
|
|
I like the creativity it requires.
Here I get called back with rectangles I'm getting from "converting" a jpeg - in this case into a raw rgb565BE bitmap form, compatible with the frame buffer of the LCD display I'm using. I'm them telling the device to do a DMA transfer from the ram I just gave it, in effect, loading the JPEG onto the display one rectangle at a time:
jpg_state js;
js.tft=&tft;
js.dma_space=dma_space;
js.size = dma_size;
io::file_stream inp("/spiffs/warhol320x240.jpg",file_mode::read);
jpeg::convert(
inp,
[](const rect16& rect,size16 size,const rgb888* bitmap, const void* state){
jpg_state s = *((jpg_state*)state);
const rgb888* end = bitmap+(sizeof(rgb888)*rect.width()*rect.height());
assert((((end-bitmap)/sizeof(rgb888))*sizeof(rgb565))<=s.size);
uint16_t* buf=(uint16_t*)s.dma_space;
while(bitmap!=end) {
rgb565 col = color::reduce(*bitmap++);
*(buf++)=env::platform::mkbe(col.value);
}
return result::success==s.tft->write(rect,s.dma_space);
},
&js);
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
