Ugly code which makes you proud

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:

No alt text provided for this image

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:

No alt text provided for this image

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:

No alt text provided for this image

Nothing too scary, but still not quite according to well-known programming guidelines. This code could have easily been refactored to:

No alt text provided for this image

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:

No alt text provided for this image

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:

No alt text provided for this image

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?

Francois Cerisier

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 !

回复
Marian Bida

SalesForce SFCC, SFRA, and AWS Backend at Serena & Lily

4 年

I still write them every day, dont worry, every one of us do

回复
Petar Parabucki

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 ..

要查看或添加评论,请登录

Milos Mirosavljevic的更多文章

  • SoC Verification VS Traditional (UVM) verification

    SoC Verification VS Traditional (UVM) verification

    "But why can't I just use our UVM testbench to verify SoC behavior?" I often hear junior engineers or those who have…

    33 条评论
  • PCIe vs. CXL vs. UCIe

    PCIe vs. CXL vs. UCIe

    Many years ago, my first project was related to PCIe Gen 3. Before that, I only encountered simple protocols UART…

    14 条评论
  • The Packaging of Microchips: 2D vs 2.5D vs 3D Integration

    The Packaging of Microchips: 2D vs 2.5D vs 3D Integration

    When we think about microchips, we often imagine tiny rectangles packed with billions of transistors. We imagine the…

  • SoC vs. Chiplets: What’s the Difference?

    SoC vs. Chiplets: What’s the Difference?

    In the world of hardware design, you’ve probably heard the terms System-on-Chip (SoC) and chiplets. Both are critical…

    21 条评论
  • Emulation vs. Prototyping: What’s the Difference?

    Emulation vs. Prototyping: What’s the Difference?

    If you work in hardware verification, you’ve probably heard about simulation, emulation, and prototyping. You probably…

    8 条评论
  • Debugging by Eliminating Potential Causes

    Debugging by Eliminating Potential Causes

    For verification engineers, the ability to quickly debug and diagnose test failures is an essential skill. My…

    3 条评论
  • How Saying "no" Helped John Become a Stronger Technical Leader

    How Saying "no" Helped John Become a Stronger Technical Leader

    John is a hardworking and highly motivated engineer who had just started leading others. He was driven by a desire to…

  • Ever heard of AWK programming language?

    Ever heard of AWK programming language?

    I encountered awk for the first time many years ago while attempting to produce a script that would effectively search…

    6 条评论
  • Apply the 80/20 principle to efficiently learn SystemVerilog

    Apply the 80/20 principle to efficiently learn SystemVerilog

    I vividly remember my career start as a verification engineer: it was in late 2011, in the cold November (this reminds…

    6 条评论
  • Initiative - Hidden Gem In Your Skillset

    Initiative - Hidden Gem In Your Skillset

    Andrew, a young engineer, started his career like most others in his profession – eager to prove his worth and learn a…

    2 条评论

社区洞察

其他会员也浏览了