Best practices, part one

file_exists vs is_file
is_file will probably give you the information needed, where file_exists doesn't. Unless you don't care whether it's a directory or a file. And is_file also returns false when a file doesn't exists

Using @ aka 'shutup' operator
@ is slow and bad. Warnings and errors are there for a reason. If you don't want to display them, create your own custom error handler and/or set display_errors to off. There are only very, very few cases where a @ is justified. Examples of this would be in use with network related code.

Notices are worse then Warnings
Errors, Warnings and Notices are equally bad. And I think Notices are even worse, mostly because most people ignore them, causing hard to catch bugs. error_reporting( E_ALL | E_STRICT ); is the way to go.

Not checking what you use
Before you use something, check if it exists and if it is what you expect it is! It sounds so logical, yet I see so many code where people don't check it, and assume. Sure, in a lot of cases you can assume or even know in advance. But if you don't, just check it. The time and resources it takes is neglectable and your code quality improves significantly.

Array fun
I notice a lot of array related code that always makes me smile. For example, how many of you do: $last = $values[ count($values)-1 ]. While $last = end($values); types a lot faster. If you care about the internal pointer you could reset, or keep the count syntax thing going, but if  you do for example a foreach after it. It's fine. Another nice one I noticed a few days ago:

Be sure to checkout all available array related functions for more handy-dandy work.

Calling public (non-static) methods the static way
Okay, no idea why you do that? Maybe because of backward compatibility, but please stop doing that. Time to let go this bad PHP4(?) habit !

PHP open and close tags
Use <?php as opening tag and don't use the asp (<%) or short opening tag <? especially not for projects you work on that are on servers out of your control. And don't use closing tags, they are not needed and can cause troubles (and not to mention silly SVN differences) while some consider this 'untidy' (which I can understand) it adds no real value to using them

Condition order
Unless you read from right to left, I don't understand people writing this: if (false == $variable) {}. Please stop doing this, it's a illogical order, in more complex condition it can increase readability to put the variable after the true/false comparison. But in almost all cases it is not. Just use: if ($variable == false) {} or better yet, if possible: if ($variable === false) {}

(Remi also has a blog post about condition orders, with a comment of why you want to have the values in the wrong order. While it's true, I still don't agree with changing the order)

Regex fun or avoid
When you need to perform validation you often know what to expect and what would be a valid input. Many people use regular expressions and there is nothing wrong with that, but few people know about the ctype family that are not only faster (on small and especially on large chucks of text), but also lot easier. What do you prefer:

Variable naming
Consistant variable naming is a blessing when reading code, especially if that code is written by someone else. Proper documentation and understandable variable/class naming is easier for everybody. A example:

Documentation
I don't think this can be stressed enough, add proper documentation to anything you write. Again, no stories. Jokes are allowed at times (in my opinion), make clear obvious comments. Use enough spacing in examples and use a common way of documenting. Choose a standard and stick with it, don't think "I will add it later" because you probably never will. Also make sure your project wiki or whatever system you use to document your projects is up to date, just give yourself a few minutes a day to write new things down, keep it up-to-date. You will regret it if you have to continue on something you wrote months ago where you didn't document anything and completely forgot about. Or worse, someone else has to.