Re: Hmm this section needs something
looked at by a smf developer (showed him your stuff ;) )
In general, whitelisting works best for security purposes as it only allows things you have defined. If you are permissive (blacklist), an attacker can try a vector you have not anticipated and get around things. Remember the principle of least privilege.
You don't need to abandon MD5, but you shouldn't be using it for security purposes. Dictionaries of common (or even all possible) hashes is nothing new. The best (and a rather old) solution is to salt the passcode before hashing it. Doing this stops dictionary attacks as even the proper reverse text will be invalid as you'd need to account for the salt value. That leaves the cracker to brute force, which will take significantly longer. MD5 is fairly quick to brute due to flaws in how it was designed, so I wouldn't use that for passwords anymore. Likewise, SHA1 has been "broken" and looks like it might start getting easier to brute as well, so look at using a more secure hash method when security is vital.
Sometimes you need a process to run once a minute, sometimes you just can't get past it. However, if you only need a job to run at a certain time, schedule it just for that time, it keeps the load down. If you need it to run periodically, always ask yourself what is the longest period it can go without running.
Expanding a bit, get a code style and stick to it. Being consistent in how you write your code will help when you need to look it over in the future.
For functions, documenting the purpose, input, and output at the top of the function is a smart thing. If you did something tricky or something unclear, put a comment by it so you know why it was done.
Keeping your code straightforward is the best documentation you can do. You don't need huge comments unless you are either doing formal code documentation or the code is so complex, you can't understand it in by scanning it over, and comments that big are often more of a hindrance than a help.