I'll add my $0.02 here, for what it's worth:

1) Column names should be fully qualified whenever possible for future scalability and performance reasons. Yes, it's tedious to always add the server.tablename prefix, but if you ever have to connect to another database and/or server, it will be INSTANTLY beneficial. Plus it's self-documenting. This eliminates the need to prefix column names with abbreviations (and removes the potential for running out of two & three-letter combinations).

2) I'm of the old-style, Hungarian-notation column-naming school - "c" prefix for character, "i" for integer, etc. It has saved me countless hours of having to look up column types in other developers' stored procs. Plus it eliminates the possibility of reserved-word conflicts.

3) I prefix PK columns "PK_" and foreign key columns "FK_" (usually with the same column name as the parent, unless the situation dictates otherwise). Again, it's self-defense, as I can tell instantly what the column is. The choice of prefixes is habit, since my case tool of choice names the columns that by default. As long as you have some pattern, you're okay.

One last habit I've adopted is to put the columns in alphabetical order. Helps to find columns in large tables easier, and since we use Hungarian notation, all like-type columns are grouped together (which makes it easy to double-check defaults, null acceptance, and so forth.

JMHO.