Code That Reads Like A Novel

I’ve run across this more and more, recently – developers who want code to read like a novel.  In other words, they want an entire application’s logic to be in one script – maybe a couple more, if the app is really complex.  And we’re not talking concatenated files, here (I’m all for those); the design should result in one script. 

I think this is so problematic. Multiple contributors to a document typically makes it harder to read.  Each dev has his or her own style, and when you start to mix them, it just becomes weird and hard to follow.  When I first started running into code like this, I adjusted my style to fit what I saw.  I thought it was a good idea.  Ten months down the road, however, when there was more work to do, I was lost.  I couldn’t remember what I was trying to do, or even why.  It didn’t save time, or make the app more maintainable.  The added (unnecessary) frustration didn’t help, either.

Changing working code often introduces new bugs.  How many times have you made a quick fix, just to later find out that you created another problem?  Happens all the time.  In small, decoupled scripts, that’s practically impossible to do.  If it turns out that something is wrong with your code, you can be sure the error is in the document that you created/altered.  No need to go searching through 1500 lines of code to figure out the issue.

Forget about replacing libraries, or even large portions of functionality.  That’s a guaranteed re-write.  Search and replace won’t save you when you when there are 150 versions of the function name you’re trying to update/replace.  In writing an elaborate to-do app, for example, you’re inevitably going to use some variation of the word “task” at least 100 times.  Sometimes it’ll be in comments.  Sometimes it’ll be part of variable names.  You may even find it in include-file names. 

Lastly, (I know I’m getting a bit long-winded here), unless you’re given a complete build, most tickets are for bug or feature requests.  In either case, you don't need to know how the entire app functions to solve the problem.  You just need to know where to implement your solution.  I almost always create new scripts, once I’ve reached this point.  When I realize I’ve misunderstood the requirements, I just go directly to that doc, and make changes. 

Ultimately, these long scripts make code more brittle.  I’m probably preaching to the choir, for the most part.  It seems most of us prefer to have our code broken down into modules/components that are then assembled in a main script (router, App.js, etc.).  Still, there are quite a few who disagree.  I’m just supporting my position.

As always, let me know what you think. 

Addressing The Problems With Object-Oriented Programming

YouTutbe is not my primary resource for learning new technology or paradigms.  I'm a Pluralsight-Lynda guy.  I still like to listen to presentations and lectures, though -  just to see what people are talking about in the real world.  There are a lot of conferences and interesting presentations posted on YouTube.

I'm an OO guy... still (I probably just lost all the functional devs, but I guess I'll be converting soon with React, we'll see...), but I do recognize the tricky issues inherent to object-oriented designs.  I was hoping this video might shed some light on what other devs do when they face similar problems.  I was in agreement with the early parts, but somewhere around that 30-minute mark, things started to change.  Then came the solutions, and that's where he completely lost me...  I think the solutions are worse than the problems.

My biggest issue with Will Brian's solutions, hands-down, is implementing long methods.  I don't even know where to begin.  They are hard to read - heaping loads of conditionals, variables, and state on you.  Accidentally breaking code because of semantic mistakes is a regular problem (unmatched curly braces, anyone?).  In Javascript, nested and inline functions lead to memory leaks.  It's impossible to reuse code that's bundled-up in another function.    It's just bad stuff.  I prefer the S.L.A.P. (single level of abstraction principle) approach, which basically boils down to new functions for every indentation.  I started doing this a few months ago, and it has saved tons of time in understanding flow, logic, and documentation (if you use good names).  I'll never go back to long methods.

Then there's the recommendation to use comments to explain what's happening in the long functions - another head-scratcher.  What's more common than an outdated comment?  I've learned to distrust them.  Instead, I follow the code.  Comments are useful when they explain why you've done something, but not to document what you've done.  Good function and variable names are better.

I'm also not sure what the problem is with "hopping" around code.  If functions are short, and scripts cohesive, you shouldn't be "hopping" far - especially if you copy-and-find.  Sublime even has a nice shortcut for specifically finding functions (control+R) - a very nice feature, indeed.  Hopping from script-to-script is painful, but as far as I can tell, it's just the price of decoupling.  I'm open to suggestions that eliminate tons of script files, but not if it means coupling.  There are always changes and rewrites; coupling makes them a nightmare.

But my intention here is not to antagonize Brian, or to try and poke holes in his coding philosophy.  Instead, I was inspired to speak my opinion on the ideas he raised.  It's a great reminder of the different types of devs we work with, and how we're all passionate about our ideas of good code.  "Object-Oriented Programming Is Bad" has nearly a half-million views, and it's only roughly a year and half old.  There are thousands of likes and dislikes - not bad numbers for a design pattern video.  Check out the comments - a lot of activity there, as well - all indicators that he has touched on very real issues.

Anyway, just sharing a few thoughts.  Let me know what you think about the video.