Eliminate spaghetti code by implementing an event system

  Follow me: Follow Bruce Kirkpatrick by email subscription Bruce Kirkpatrick on Twitter Bruce Kirkpatrick on Facebook
Wed, Jan 23, 2013 at 5:10PM

"Spaghetti code" is not just talking about object oriented programming vs procedural, it is also saying something bad about how those elements are connected.   A lot of times, when editing bad code, it's like trying to take one of the Christmas lights out of the box and finding that all of them are pulled out at once.  This forces you to unravel the mess and remember which things are tangled where.  The bigger the box, the more effort this takes.   Ultimately, you are able to get through it, but there was lost time.   Perhaps some people are even faster at untangling it, but you still lose some time even at the genius level of untangling.  

How does this relate to programming?

In programming, it is essentially the same process of untangling that box of Christmas lights, but most people have to do this not with their hands but with their short term memory.  People who can remember vast amounts of detail in their short term memory will excel when working on a messy program.   Unfortunately, many applications are built with tight deadlines and poor quality leading to this happening frequently.  It gets to the point where it seems like only smart people be programmers, but it's actually the smart person being lazy or following bad management decisions which is the problem.  

Showing off your vast intelligence by writing complex code ends up hurting the rest of the team eventually.  Maybe programmers keep doing it this way because they've never found a better way and felt that it was too hard to change now.   To some extent, we just don't care when there is a deadline.  We can always hack together whatever works and achieve the client requirements.  However, in a large system where maintenance becomes more costly then initial development, this is a huge problem.

How do we fix this?

"Hooks" or "events" are a commonly used way to allow things to connect to each other without needing to hard-code that relationship directly into the code.   Hooks are also nice because they don't dictate that the plug-in has to be an object, it could be just a function.  That reduces the amount of code needed to build them.

Consider that both MediaWiki and WordPress rely heavily on providing hooks for plug-in developers - as does most other software including bigger applications like Windows and Linux.

Hooks are generally setup as a point in the code that triggers an event.  Other features in the system that register to listen to these events will then be executed.   Nearly all something that implements a visual interface is relying on events like this to translate user input into commands.   However, even non-visual systems like back-end servers benefit from being event-driven.

Example of a hook in a backend system?

When you click "Save Article", there could be a hook named "ArticleSave", which allows you to add custom validation before the article is saved in the database.

Applications can have hundreds of different hooks like this covering things both small and large.

Do hooks slow down the code? 

Not too much if it is well optimized.  With CFML, it is possible to store the registration of a hook during start-up in shared memory so that each request only runs them instead of needing to determine which objects are registered on every request.  In some languages like PHP that don't implement shared memory as fast, will suffer from more slightly more overhead or require more elaborate organization structures to be fast, but most modern hardware can make these differences seem less noticeable.

Status of using events in our application

My applications currently only use hooks such as on application start, on server start and on request start.  We don't implement hooks that determine how different features integrate yet though.  I've always hard-coded references to other code when connecting different systems.   This sometimes leads to needing to understand a lot more of the system when editing each feature.   My code could be considered spaghetti code because of this.   Despite my attempts to eliminate redundancy and complexity, the connections between each feature are still rather messy and this is an area where big improvements can be made.

Our First Hook

Today, I successfully implemented a simple hook system that registers a hook during start-up and then executes it when that event is triggered.  With this system in place, it will become easier to start separating all of the individual features from each other more thoroughly.  This will make the system have a structure for extending it that will be less difficult for other people to understand.  The code to build this hook system was small, but it will have a big positive impact on the cost of maintaining our projects in the future.


Bookmark & Share



Popular tags on this blog

Performance |