Evan Teran's Blog

Casey Muratori is wrong about clean code (but he's also right)

First things first...

I'd like to get one thing out of the way. Despite the click-bait headline, I think that Casey is right about a lot of things. It seems to me that programming for performance is becoming a lost art and I think Casey is doing great work as an advocate for writing code designed to perform well. So I agree with many of the principles he talks about and feel that he is shining a light on how non-performant most of the code we see today is. I hope he continues to do this. As someone who self-identifies as a developer who loves to optimize code and squeeze every last bit of speed out of it, I find myself nodding along with many of his points. Everyone should read his blog post at https://www.computerenhance.com/p/clean-code-horrible-performance too see a good demonstration of how he uses his principles to squeeze a ton of performance out of one of the first examples of OOP that beginners get shown in school.

I wouldn't be writing this unless there was a "but", so here we go :-). Spoiler alert, in the end, it's complicated and there are no hard and fast rules. Always profile your code to know what is fast and what isn't!

UPDATE: A reader on reddit pointed that the shapes were in a predictable pattern. So I've added one last section to the end to test again with some randomization. The results continued to surprise!

Adventures in non-deterministic code (Always initialized your structs!)

I've been working on an old code base lately. It's a relatively simple data in/data out, kinda program. But It's also a bit messy, written in C using outdated techniques, and suffers from memory leaks. So I am going through the process of cleaning it up and porting it to C++ so the code can be made simpler and easier to manage.

Being that I didn't write the original code, my first thought was to create some sort of regression tests. My plan was simple. Run the code on a bunch of varied input files, and save the output. Now, every subsequent run I can just diff the results with the "known good" ones, and I should be good to go... right?

Sadly, this was not the case.

Moving printf into the modern age using C++17

Ever since c++11 introduce variadic templates, I started seeing people implement some "safe printf" examples. They are pretty cool, but none of them attempted to actually implement the printf fully with all of its quirks. Instead, they all pretty much do the same thing:

Use variadic templates to verify the sanity of the parameters
Delegate the actual formatting to the libc printf

I think we can do better...

Well This Is Embarrassing (I Got Hacked)

I suppose it happens to everyone eventually. My blog got hacked. :-/

Portable BitFields Using C++11

There are lots of reasons for using C++'s bit field feature. Perhaps you need a more compact way to represent your data structures, maybe you need to use them to interact with hardware, or if you're writing an emulator, maybe you want to use them to efficiently represent the hardware that you're emulating. The list goes on...