A few years back, Alvin was in college, and took his first formal summer job as a programmer. It was supposed to be just some HTML layout work, and the designer handed him a few sample pages. "Just do it like this."

The "sample pages" were a mishmash of random indentation, huge swathes of commented out code, and all those other little traits of "someone's just coding in production, aren't they?" that crop up in files. Still, it was just some HTML layout work, so how hard could it be?

Operator overloading is one of those "dangerous" features. Like multi-parent inheritance, it can potentially create some really expressive, easy to read code, or it can create a disaster of incomprehensible nonsense.

In C++, many core classes use operator overloading, most notably the I/O classes, which reuse (or abuse) the bitshift operators into stream operators. So, for example, one possible way of converting a string into an integer might be to do something like this:

Maximillion was hired to maintain a PHP CMS. His new employer, up to this point, had just been contracting out work, but as time went on, contracting rates got higher, the amount of time required to add basic features kept going up. It was time to go ta a full time employee.

"The system's pretty simple," the hiring manager explained during the interview, "as I understand it, it's basically just one PHP file."

Cornelius was working with some code where the objects might be "active" or "inactive". His code needed to do something different, depending on whether the objects were "active" or not, but fortunately, there was a handy-dandy IsActive method. Weirdly, that method required a bool parameter, but also returned a bool. Since there wasn't any useful documentation, Cornelius checked the C++ code.

    bool SomeActivatedClass::IsActive(bool& active)
    {
        active = true;
        return false;
    }

Matt has plans for the next few years: dealing with the "inheritance" of some legacy systems.

They're written in VB.Net, which isn't itself a problem, but the code quality leaves just a bit to be desired.

Jesse had a "special" co-worker, Rupert. Rupert was the sort of person that thinks they're the smartest person walking the Earth today, and was quite happy to loudly proclaim that everyone else is wrong. Rupert was happy so long as everyone else was ready to bask in his "genius".

Fortunately for Jesse, Rupert left, because he'd received a huge offer for a senior developer role at a different company. Everyone at Jesse's company privately chuckled about it, because this is the kind of code Rupert's genius produced:

Virginia N (previously) needed to maintain some authentication logic. The actual rules for authentication weren't actually documented, so her choices were to either copy/paste some authentication code from a different project, or try and refactor the authentication method in this one.

It was a hard choice. We'll dump the whole block of code, but I want to pull out a few highlights, starting with the opening condition: