What's your favorite "abandoned rule"?

Question

Like children, programmers are often given the information that they need for their profession in the form of inviolable "rules". Like children, we often follow these rules unflinchingly until one day, by accident more often than deliberately, we don't follow the rule, and nothing bad happens. Maybe we even see that not following the rule makes our lives easier and our code works better.

My favorite abandoned rule is:

Never use SELECT * in a query

I absorbed this rule while learning SQL the night before my first day at my first IT job (1996) by cramming a book on Access. The book spoke with the ferocity of a televangelist about how a baby kitten is drowned whenever a programmer uses SELECT * in a query, and I believed.

For years I never ever used SELECT *. One day, I was writing a query like

SELECT COLUMN1, COLUMN2, ... COLUMN472 FROM tblWHYTHISMANYCOLUMNS

when it occurred to me that since I was just asking for every column in the table, I could save some time by typing

SELECT * FROM tblWHYTHISMANYCOLUMNS

I tried it, and amazingly it compiled and ran perfectly. I've been an asterisk-man ever since. Nothing bad has ever happened to me as a consequence.

So what's your favorite abandoned rule?

Answer 1

Never tell "I will never use <bla-bla-bla> ".

Answer 2

This might be naughty...but:

Write tests for your code before you write the actual code.

Oops...that almost never happens.

Answer 3

Depending on how much of an exaggeration COLUMN472 is, having to specify columns may not be the only issue with your application.

(I'm kidding, I'm kidding ;)

Answer 4

Hungarian notion (at least in the microsoft longpointertosomethinginmemoryonacomputer form)

ps. Yes I do know the correct use of Hungarian notation and I do use that.

Answer 5

Never use gotos.

Used correctly they can be immensely useful!

Answer 6

"Premature optimisation is the root of all evil."

People -always- take it out of context. There was the question just asked an hour ago about it on the algorithmic scale; people usually don't know the full sentence. He was talking about things like using "myInt << 1" instead of "myInt * 2" etc.

I used to try and keep my algorithms as... Well, not simple, but brute forced. I quickly learned, however, that in a real time ray tracer, you kind of need decent PVS (Potentially visible set); I had to rewrite most of my code to do it properly.

Answer 7

Every function should have only one exit point.

This got thrown away as soon as I graduated.

Answer 8

I've been known to abuse loop (mostly for loops) semantics to do some fun/interesting stuff before. I mostly blame the time I spent as a perlite, where you can get some interesting one-liners that way. The most recent of these would have to be (C#):

readonly string[] prefixes = new string[] { "", "K", "M", "G", "T" /* etc */ };
public function NumBytesToString(int bytes)
{
    double d;
    int i = 0;
    for (d = bytes; d > 1024; d /= 1024) { i++; }
    return string.Format("{0:0.00} {1}B", d, prefixes[i]);
}

Answer 9

"Never take sleeping pills and laxatives at the same time" - oh wait, that's not to be abandoned :)

I was particularly happy to abandon the "use tables for layout" from web 1.0.

Answer 10

I dropped any rule that began Never do ... I'd say never say never or, if you prefer, there are usually exceptions ;D Select * is ok, although I personally use tools to do the bulk of the writing when doing large queries. FWIW I'd say don't use select * when also using "into" like: "SELECT * INTO #TEMP FROM REALTABLE WHERE COLX = 1" because if the structure of REALTABLE changes it can mess stuff up...

Answer 11

This is more of a design principle than a "rule", but 3-tier design is something I've enjoyed abandoning (in the sense of I don't feel obligated to use it everywhere).

I have seen countless applications in the wild that had a middle "business logic" tier that did nothing more than hand data tables back and forth between the data layer and the UI layer.

Sometimes (if not most times) your app is just tables in a database and a UI for manipulating that data.

Answer 12

I was once told that writing clean code for everbody understand included not using short if form like:

$data = (isEmpty($field)) ? "Default Data" : $field;

But I just can avoid it ... I even think this is more clear than

$data = $field;
if (isEmpty($field)) {
    $data = "Default Data";
}

or the else {$data = $field;} variation ...

Answer 13

Unit Tests on the UI, they're a bugger to do and too easy to ignore

Hungarian for UI Controls (makes them easier to spot in Intellisense)

Commenting ("Good code should comment itself - just don't ask me to explain why in a month's time" :)

Answer 14

Think everyone's broken this one:

Design first, code second?

Answer 15

I quit using CamelCase a while back, and I feel better about not using it every day.

Note: IIRC, among other things, asterisk makes two trips to the database, one to get the column names and another to run the query. A lot of these rules have uses that make sense (otherwise they wouldn't ever have become rules), so I would not ever permanently abandon any of them as options.

Answer 16

Always use curly-braces around code-blocks, even though the language may not require it

This is a common "best-practice" suggestion that I have heard throughout the years, and it wasn't until recently that I have realized why I adamantly disagree with it.

Consider the following example:

if(myDevice.hasConnectionError())
  FaultResponseManager.submit(myDevice.getLastError());

If we assume the above code snipplet is apart of a code-base where all error conditions are expected to be handled exclusively by the FaultResponseManager (as per design decision), a perfectly clean way to discourage other developers from adding other code to the block of this if-statement is to simply drop the curly braces. This makes it clear that the original intent of the code block is to do exactly one thing.

Answer 17

In Java some people keep coding following the rule, that you should assign null to references that are no longer in use. That should help the garbage collector to reclaim the memory taken by the object the reference was pointing to.

This rule is completely outdated, on modern virtual machines it makes the Garbage collector actually less efficient!

Answer 18

I'm taking JayTee's comment at face value, although I don't believe that "use tables for layout" was ever a rule, so much as a de facto standard.

There is, however, that "don't use tables for layout" — or anything other than "tabular" data — rule, which is my personal favorite to abandon.

I've never been punished, or suffered in any way for breaking this rule! I've suffered a lot more over trying to answer questions like "How do I achieve x without tables?" In "both" browsers. Good riddance!

Answer 19

Never use "magic numbers".

Often they are obvious, and a constant/#define actually obfuscates. In other cases, a judcicious comment is preferable anyway, as the description is where it is actually being used, rather than hidden elsewhere.

Answer 20

You should NEVER, EVER use exceptions for control flow.

And then Python came.

Update: Having become familiar with Erlang, I'll have to add that to the already enormous list of [Python].

Answer 21

Design frameworks, or so called re-usable code.

In my experience I have very seldom seen code been used outside their original place, but still I and others have designed stuff to be more portable than necessary. Nowdays I clear with customers first, then it often will be designed to ship.

Link on subject

Answer 22

Not using curly braces for everything.

http://leepoint.net/notes-java/flow/if/30if-braces.html

Answer 23

1) Every line of code should have comments.

++age; // Increment age
result = 42; // Assign 42 to result

2) Use unsigned integer types for numbers that can never be negative.

3) For better performance, use the smallest integer type that can hold your number.

Answer 24

"always design tables with 3NF in mind"

turns out that sometimes performance gets a hit when always doing 3NF