There's been an off and on discussion with some peers in email about the issue of putting small code functionality directly inline in a bigger function vs. splitting it out. I don't think it's actually an interesting topic so I don't want to repeat it here, but it made me think of something I want to write about.
Basically the contention is that even if you have a logically separate piece of work, sometimes it's better to go ahead and write it inline in the larger function, because it makes the code flow more linear and imperative and thus easier to read and debug. There are also obvious disadvantages to writing code inline - less strong separation of functional bits, temptation to copy-paste code, less ability to debug and test functions independently, etc. etc. All the pros and cons are obvious and thus not interesting.
The key point to me is the issue that while code inline may be a win sometimes - it's a big loss at other times, and it requires you to make a careful smart logical decision about which way to go.
That's very bad. I think most smart people as they get older come to the realization that you shouldn't put yourself in positions where you have to make careful logical decisions over and over. Instead you should craft habits and rules for yourself that help you do the right thing without having to make careful decisions.
One obvious case that most smart people figure out is diet and exercise, or booze or other indulgences. Yes, it's perfectly fine to have a some dessert once in a while, but if you open that door for yourself you're putting yourself in a situation where you are consciously making a decision "is it okay for me to have cake today?" and you will inevitably get lazy and make the wrong choice sometimes.
As usual the best analogy is poker, and it's how this point was really made real for me. Smart people often start out playing poker trying to logically reason out every single action and think they don't need to be constrained by simple rules or habits. That's great if you really are correctly thinking through every situation, but you inevitably get tired or lazy or make mistakes, and if you're not constraining yourself with rules, you can make huge mistakes.
For example, there might be cases where the best play is to limp aces up front, or to not reraise with aces, but correctly making that decision requires a lot of careful thought, and the upside to making that decision is pretty small, while the downside to doing it in the wrong situation is very big. It's best to just make a rule for yourself that you always raise or reraise. It simplifies things, it removes decision points and lets you focus on more important issues. It might be +EV to call raises sometimes with hands like 68o, but it's best to just give yourself a rule that you never do that.
To be clear - these rules are specifically non-optimal. By making rules for yourself you are intentionally choosing to not try to be 100% optimal, so of course someone can say "you could have done something better there". That's not the point. The point is that if you try to make perfect decisions all the time you will occasionally fail very badly.
Winning poker play (or good coding, or good life living) are largely about making it easy for yourself to do the right thing.
my personal favorite is the local function. Keeps code flow reasonable, but doesn't duplicate code everywhere all the time.
its exceptionally convenient when you want to qsort or std::sort. No more hunting for the correct sort function, just put it inline.
Actually I really don't like the local function. It's basically the worst of both worlds. It makes the code flow nonlinear, and it also fails to make a robust utility function that's easily shared and reused. The fact that you can't use it in templates makes it basically useless in C++9x.
Also it's another conscious choice which means another possibility for mistakes. If there's a valid complaint about C++ it's that it gives the practitioner too many difficult choices in how to write code. Most modern variants like Java and C# improve C++ by greatly reducing the ways you can do things.
In other new, the way Blogger loads the page, auto - logs you in, then resets the page is really fucking killing me. Fix your shit Google. I keep typing things in the comment box then having them wiped out when the page finally finishes loading and decides to reset and hammer on my progress.
I've written about this bug before, but it's much worse now at my house because my internet is so fucking absurdly slow.
yeah, I'm really looking forward to lambda functions in the new standard. local functions make some things nice, but the certainly have their drawbacks. One large one is that they are hard to debug as the debugger messes up quite frequently in them. In general I'm a big fan of linear code. None of that function fan-in fan-out stuff just because. If it makes sense to do it that way, then do it that way. Otherwise keep it simple.
btw, the linear code argument is not a new one. Its been around since the inception of high level programming languages. I can't find the article at the moment, but there have been studies done, and people aren't very good at understanding code that isn't linear. This is taken to extremes in other industries (like the aviation industry) where people's lives are on the line. They don't like to have any branches in their code flow at all if they can help it. One bug after all can cost them huge amounts in court, as well as its a stain on their conscious. However, this leads people to places they don't like to be.
People are sometimes a little over passionate when it comes to their language and coding style of choice. I try to have no opinions myself and keep an open mind. Afterall, in some places I'm sure C++ makes excellent use, however in others it probably hurts more than it helps. All to often I find people using virtual functions for example when there is absolutely no need for it. Just because they might at some point in time in a mythical future. Maybe I should write a blog entry. This comment is getting a little long.
Damien Dracon is back in Devon Falls, and he is about to woo the one lady he left three years ago. Family secrets and youthful pride forced him to give up the one good thing in his life: the love of Alicia Stevens. What he doesn't expect is that Alicia has a secret of her own, and it may just tear them apart.
Can two former lovers find it in themselves to forgive one another and let love grow between them? Or will past secrets haunt them and tear them apart?
Damien and Alicia are both dealing with broken hearts and the loss of their infant daughter, in their own ways. Delight adds such a tremendous style to bring the reader into the story and feel for each of their pains and sufferings. Empathy, sympathy and heartbreak can be felt.
I have read all of these Devon Falls books by Delight and I have to say, as each one moves to a new couple in town... Delight strengthens the bond of love with each person. I completely adore the characters, their connections and the way Delight entwines Damien and Alicia by having such a tight connection from their past. The brooding Damien and sweet Alicia, deserve their story to be told and Delight does a magnificent job of doing it.
I look forward to the fourth installment of the Devon Falls series and hope Delight plans on continuing the series further. This book can be a stand alone but I recommend any lover of romance to start from the beginning and fall in love with Devon Falls and its residents as I have.