It's sometimes hard to satisfy a sense of humor when programming. But remember that the joke wears thin after a while, so it is almost never worth including a joke within production code. It's hard to tell what circumstances it will come up in later, or with whom it will come up.
I once had a manager encourage me to slightly rename a component named with an acronym. It was to become the "File Update Control Module". I called it something else. Which made it easier to not add insult to injury later during customer support issues.
Another time, I had a program that had some functionality that included doing two complicated calculations that culminated in comparing the two results with each other. Although I named the functions well to self-document what each calculation result was, I still called the two final variables "apples" and "oranges". It was apparently a slow day, so I amused myself by having it then compare apples to oranges at the end. The code reviewer was amused as well, but their advice to name the variables more appropriately was good. The joke wears thin, and any amusement is more than offset by even a little extra cognitive load on anyone else years later trying to determine what that code was doing.
One co-worker liked setting flag variables to a value of -666. He would name a constant "HellFreezesOver" just so he could have code containing "do...until" loops that included "until (HellFreezesOver)." One time that value bled out into an error message reporting error code -666. A customer already impacted by the error expressed not being amused by the error code. Will a customer to feel an issue is being taken seriously if the error message itself appears to include a joke?
No comments:
Post a Comment