Author: paletz

There are many documented code anti-patterns on the Internet, but I came upon one in a pull-request review that I couldn’t find any mention of. Let’s document it here!

Proletarian Executive is an anti-pattern where a low-level function or class makes high-level decisions in a manner that violates the separation of concerns. It contributes to spaghettiness of the code base.

It can start as a welcome trade-off, a hacky one-off solution, but as the development continues, similar problems might arise in the same area, which attracts similar solutions.

The correct way to remove Proletarian Executive depends on context.
Inversion of control might help in cases where high-level logic needs to be executed inside the proletarian.
In other cases, the high-level logic can be “simply” moved to the proper level.

Command-line shells are powerful tools, even the best UI can’t be as flexible as a command prompt. Especially if you want to use multiple programs at once, pipe output of one into input of another, etc. But if your workstation happens to be a Windows machine, it can be a struggle. Seriously, cmd.exe is a very poorly engineered command prompt, and that was the only reasonable built-in command-line until PowerShell was introduced in around 2006.

We poor Windows users face many challenges. Let’s dive into this rabbit hole…

Continue reading “Windows prompt tricks”

I had to work on a legacy C++ code base that doesn’t use smart pointers, everything is instead tracked by plain pointers. The original reasons for that include downright crappy compiler and just the code being quite old. Nowadays, I don’t see anything preventing the use of smart pointers in the legacy code base.

The question is, how do you transition from plain pointers to smart pointers when you have a big code base that cannot be updated over night.

I’ll present some techniques in this post. You can also check out my video on the same topic.

Example

Let’s suppose the code looks roughly like this:
(The actual legacy code base looks much worse, but let’s focus on the pointer business.)

bool createDestroyable(Destroyable *& destroyableOut)
{
    destroyableOut = new Destroyable;

    if ( !destroyableOut->init() )
    {
        destroyableOut->destroy();
        destroyableOut = NULL;
        return false;
    }

    return true;
}

bool legacy()
{
    Destroyable * ptr = NULL;
    
    bool rc = createDestroyable( ptr);
    rc = rc && ptr->doStuff();

    if (ptr != NULL)
    {
        ptr->destroy();
    }

    return rc;
}

And that’s just an example, there are many functions like createDestroyable() and even more call sites, so it is impossible to change the signature of createDestroyable() and update all call sites in one go.

Continue reading “Gluing Smart Pointers to Legacy Code”

Back in January I embarked on a C++ Metaprogramming Adventure. I thought it would be a fun experiment to try implement named parameters in C++. Indeed it was fun but infuriating as well at times, especially when compiler started throwing internal errors 🙂

The primary goal was not to achieve something that I or anyone else would actually use. I fully expected the overhead in terms of performance and more importantly in terms of code readability to be too much. If you are looking for an actual viable solution for this problem, it looks like boost includes a rather good one. However if you are looking to learn some interesting metaprogramming techniques, you’ll find plenty in this article.

What is metaprogramming anyways? Well, programming is about telling computer what to do with input data and what to output. Metaprogramming is about telling computer what to do with a program. I did not modify the compiler though, the adventure took place within the confines of C++ code. However, what I tried to achieve sounds more like a language feature than just a library function and that’s why I call it metaprogramming.

Continue reading “C++ Metaprogramming Adventure: Named Parameters”

Warnings are one of the few weapons compiler has in its disposal to draw your attention to potential defects. It works well until there are too many of them and that’s why some developers eliminate them with extreme prejudice. If your team naturally gravitates to a warning-free codebase, good for you, but not many teams are like that. Let’s talk about a team/codebase where warnings got out of control and now there is a flood of them. At that point the one new warning that just popped up won’t get noticed at all. This effect can also be amplified by complex build where many warnings that pop up are not relevant to the code you are working with and/or when the build tool doesn’t distinguish warnings from other output well. And then someone gets fed up with the situation and decides to suppress majority of the warnings so that at least something is visible.

I see you have important warnings in your build output… It would be a shame if someone suppressed them.

You can’t even be mad at that person, because looking at build output is now arguably much more pleasant. It’s so easy to give up. But quitters never win. Over time more warnings pop up, and no one cares. Some of them turn into defects. And then you spend 20 hours fixing a defect that was caused by a line the compiler was complaining about for the past month. Or it would be complaining if it was not suppressed. Now you get it, quitters indeed never win. But how do we fix it all now? There are several options.

Continue reading “Waging War against Warnings”