Some rules I've more or less made up that I think help lead to clean, easy code. These rules are flexible, and shouldn't be followed to the letter, but they are useful guidelines

the 80x25 rule

code should fit on a 80x25 screen. If a function is longer than 24 lines long then it's probably doing two or more things and you should split it into multiple functions, or you should consider a loop. If a function is wider than 80 characters, then your logic is probably too complicated and you should split your inner loop, or conditionals into a seperate function or similar.

Dont store calculated values in the db

Don't bother, it's too easy to get DataSkew?, and you waste disk space. Occasionally you want to cache values, but make sure that they can be easily recalculated, and write a script to revalidate them regularly to check for DataSkew?.

Don't mix logic and display

Programs should generally have a clear distinction between the business logic and the display code. Business logic should be in libraries mostly. Programs in general follow "Input" "Processing" and "Output". This means that when a user clicks "add" it should call a 'addData' function that calls a validate function then adds the data to the database. Other routines that add data should go through this addData function. This means you probably should only have a couple of functions per table, a validate, a get, and a put. This is done most obviously with 3 (or n-tier) business apps where the display and processing is done possibly on completely different machines.

Database bitfields

Really really bad idea. There are boolean values for a reason.

Name id fields after the table

if you have an "id" field for a table, call it "tablename_id". If you are referencing a key in another table in a schema, give it the same name ("tablename_id"). This means that JOIN's work automagically with no pain.

Deleted flags

have deleted flags instead of deleting records from the table, have a last_modified and set it to the date they were deleted. have a script to cleanup all deleted records after a month. (delete from table where deleted='Y' and last_modified<now()-30*24*60*60)

Limit Scope

make sure variables, and, as much as the language allows, functions have the smallest scope possible. This means when you come to modify your code you can easily see how much impact it is going to have. Your compiler will also love you since the less scope something has, the less unknowns there are and the more optimisations can be done. This is particularly obvious if, in gcc, you make a function "static". This rule is a generalisation of the 80x25 rule above, and the "never use globals" rule that you are sure to know about.