Do you have your own DNUT/NDT ("Do Not Use This/Never Do That") list?

Question

I was reviewing this morning a piece of code written by a beginner, when I found these lines:

If
...
ElseIf
...
ElseIf
...
Endif

I told him "Please, Do Not Use This". And the other guy sitting aside (more experimented) said: "Oh no DoN't Use This!". I think there are many reasons explaining this reaction:

• a bad experience when we first discover the instructions ("Great, it's like a SELECT but it allows to compare more than one variable") and were finally very disappointed trying to put together multiples overlapping elseifs that no one could ever never debugg properly ...
• The elseif trick does not allows you to align your lines of code as you've been doing it for the last 175 years, where you can visually check and adjust the quantity of endifs to add at the end of your procedure.
• But most of all "what is the interest of something that is already correctly done by the traditionnal IF/ELSE/ENDIF or SELECT CASE statements?"

Another example of a DNUT/NDT item was this "cascade update" thing in SQL SERVER, which seemed to me at first glance a great trick ("Wohh! my keys are automatically updated anywhere in my database"), until I began to think that a really effective key should never be updated, so I banned the use of this cascade update thing in my databases a few hundred years ago, and, until today, nobody complains about that!

I am sure that each one of us has its own DNUT/NDT list, and I am sure there is plenty of time to spare by sharing this kind of knowledge!

Answer 1

GoTo.

Rem instead of ' for comments in VB.

Separating fields in a SQL SELECT with commas at the end of the line instead of the beginning:

(way I used to do it:)

SELECT
    Field1,
    Field2,
    Field3

vs. (post-enlightenment:)

SELECT
    Field1
    ,Field2
    ,Field3

I am told Cursors in sprocs are to be on my NDT list.

Answer 2

DON'T DO: Exception suppression

NEVER EVER

try
{
    // stuff 
}
catch(Exception e)
{}

even if you think you are going to fix that later.

EDIT: the 'code smell' here is twofold: first the exception is masked, neither thrown nor logged, so you will have a hard time finding out what went wrong, then you catch a "generic" Exception without any chance to address the specific problem and attempting to solve it or provide the user with a meaningful error message which in turn may help him/her to address it.

Answer 3

Do not use:

• Goto
• fall-through

Answer 4

DON'T DO: Commit broken code

Answer 5

In C, always put parentheses around bitwise operators (&, |, ^) when used in a complex condition. For example instead of

if (a & 1 == b & 1)

use

if ((a & 1) == (b & 1))

Because bitwise operators have surprisingly low precedence.

Answer 6

DON'T: Change other people's code without running the test suite to ensure you did not break anything

Answer 7

DON'T: Copy and paste code

Answer 8

DON'T: Eat yellow snow.

DON'T: Leave test pop-up messages or prints to the screen in checked in code...

Answer 9

Don't use uninhibited globals in a multi-threaded program. Unless it absolutely, positively will not under any circumstances change beyond initialization.

If you have to use a global, STM is a lifesaver.

Answer 10

DON'T do tests in a production environment.

Answer 11

Don't make your boss' boss look bad.

If you do, you may find yourself on the receiving end of the "Not being a team player" speech, which sets you one step closer to not getting paid for programming.

Answer 12

NEVER manually ref count a COM object. One of two things will happen

1. You will get it wrong
2. The next guy will screw it up

Answer 13

DON'T: Assume it works because you know it can't possibly go wrong

Answer 14

DON'T do a an ad-hoc delete on a Production system without wrapping it in a transaction. Run it once with a rollback, and then run it again and commit. No-one wants to restore a database because you forgot your where clause.

Answer 15

1. Don't do anything in a hurry!

   Go as fast as you can without compromising:

   • security

   • quality

   • performance

   • presentability of the behind the screen magic (source code, SQL, etc)

   If upper management wants something done yesterday, try to educate them, and get them used to having things ready at the right time (done properly).

   Rather than solving something Mcguyver style in no-time, but horrible to maintain.

   another big Don't for me, but not so immediately programming related perhaps for some:

2. Don't stop reading and educating yourself.

3. Don't forget to delete old development environments or whatever you don't need.

4. Don't replace source code versioning/control with full machine backups :^) they do not service the same purpose.

Answer 16

Do not put anything in the code that you wouldn't want a customer to see

Answer 17

DON'T use the token-concatenation operator in C++.

'##' is evil, evil, evil, evil, evil.