Ugly code which makes you proud
I still remember those first lessons in programming back in high school, some fifteen years ago. As it had been a custom back then, we started our journey with PASCAL - the first love of many programmers of my generation. One of the first things we saw were hieroglyphs like below:
Soon after the initial shock of not understanding anything, we started to learn how to write "proper" code. Starting from the simple rules of indenting, to the way you name variables. Meanwhile in the industry, dozens and dozens of books have been written related to this topic, and among many advices and guidelines, are: add comments to your code, the simpler the better, various naming conventions, decouple the design, favor composition over inherritance and principle of least knowledge, just to name a few.
Fast forward and here I am working on a big-real-life projects for some time now. And this is when the challenges begin. Your inner self wants to write a perfect code, at least as much as possible, but on the other hand, deadlines lurk in the dark. This means that significant amount of time we have to compromise between code delievery and code "prettiness". Not all solutions we pick can be ideal. Some can be improved along the way, some will be almost perfect and some will be pretty bad. After all, it depends on many factors.
Having said that, I decided to share some of my "ugly" programming code I have written over the years. Sadly many others are lost, as I started logging this kind of stuff not too long ago. Hop on and enjoy the ride!
First attraction is:
This was osbiously related to some cycle-accurate verification, but it still looks scary. Change something else somewhere, and this code is bound to break. Just by looking at it I get shivers.
Next we can see an example of code redundancy and repetition:
Nothing too scary, but still not quite according to well-known programming guidelines. This code could have easily been refactored to:
But, when you need to finish something by yesterday, sadly you don't really think about improving the code that already works. Even the above refactored code could further improve on, because obviously there is repetition - two variables with different names conveying the same information - that timeout passed on channel 0.
Now, most of my colleagues and friends know that I love mathematics. Beauty of it is for me comparable to the beauty of the finest art out there. There was actually a study which said that observing famous and complex mathematical equations invokes the same brain activity as when in an art musem (link_to_study). But, I digress, let's go back to silly code examples.
Fasten your seat belt and behold this mathematical wonder:
Some advanced thinking there, which probably occured behind the scenes. We may never find out.
And now behold!
Have you ever imagined (I appologize to my non-verification readers here) that you will see a potentially never-ending while loop in a post_generate() tcm? Me neither, until I coded it myself:
I still have nightmares of this one. Eventually requirements had to be adjusted, so different approach was chosen.
Striving for perfect code is not always the right direction anyway. As elaborated in the awesome book - The Pragmatic Programmer: From Journeyman to Master, we can discipline ourselves to write software that's good enough - good enough for our users, for future maintainers and for our own peace of mind. Good software today is often preferable to the fantasy of the perfect software tomorrow.
On a personal note, I always try to learn from my mistakes (not only in programming) and examples like these shown here, remind me to never stop exploring, learning and improving.
What is the "ugly" code you are proud of? Do you have some interesting stories to share? How do you balance between deadlines and writing code according to all those guidelines?
Founder/CEO at AEDVICES - !!! HIRING !!! Design & Verification / Design House / Trainings !!! HIRING !!!
2 年Before Pascal I even used 'goto' in BASIC . I really thought my 200-loc programs were nice at time. We have all written ugly code since. When the release is for yesterday the quick-and-dirty paradigm just catches us. Hard to be quick-and-not-so-dirty !
SalesForce SFCC, SFRA, and AWS Backend at Serena & Lily
4 年I still write them every day, dont worry, every one of us do
Salesforce Commerce Cloud Developer @ Tryzens | B2C Commerce Developer | SFCC | SFRA | Composable Storefront | PWA
4 年Hey Milos, you have very interesting point here. In future I would also try to track this kind of stuff. However, I always prefer the code which is stupid and simple, especially in the situation which you have mentioned - real life project with multiple programmers working in parallel. Also what is very important here to know, is that until we see bad code in the past this mean that we are evolving and improving. We should not look forward to the day when we say ‘who is the genius who wrote this, because I wouldn’t think of it’ and it turns out to be us ..