Here's my list, but anyone can add up to it. Id like to see how many we can come out with.
1. Public Properties/Fields:
For good object oriented programmers, every property/field defined in a class should be private or protected. The problem with public properties is that they completely break encapsulation and expose the object's basic implementation details to client coders. Moreover, public properties can be modified or erased accidentally, not appropriate for security reasons too. There's a reason why in C++ all properties are private by default.
2. Static Properties/Methods:
Static properties/methods skip the fundemental object instantiation process and introduce global scope, they are not even object oriented. In Java/C#, Static is often used with Singleton(an infamous anti-pattern) and Factory design to compensate for the lack of global variable support, but does not really make the program any better. Static properties/methods are difficult to debug as well, so use Dependency Injection as an alternative.
3. Too many if/switch statements:
You cannot write a program without conditional statement, which is why pure OO is difficult or impossible to achieve. However, its always a code smell if your program contains too many if or switch statement, especially the latter. In many cases, its possible to replace conditionals with polymorphism. a very good example is when you have switch statements checking for types/genres. For if statement, things may get a bit trickier, its up for the programmer to decide whether to refactor.
4. Long class/methods:
Long class/method usually is a code smell, it implies that your class may be a 'God class' and that your method needs refactoring. The book PHP Pro refactoring introduces many techniques for cutting down the size of a class/method, lots of them are really useful and Id recommend it to newbies. Class and method design should both follow the single-responsibility rule, otherwise it may be a sign that a class/method needs to be broken up into parts.
5. Inheritance Addict:
Inheritance is a great OO technique, trust me it is. It is one of the four fundemental OO concepts(the other three being encapsulation, polymorphism and composition), you cannot build a fully functional OO system without inheritance. However, sometimes inheritance can break encapsulation, while composition is usually better than inheritance. Use inheritance when there's a strict is-a relationship between one class and another, dont overdo it.
6. PHP Array Addict:
PHP arrays are a poweful tool, unfortunately they are not object oriented. PHP offers two object oriented way of Array handling, SplFixedArray and ArrayObject. Use for the former for numeric array and the latter for associative array/hash, it may be a good practice to extend these classes to add more functionality. The fact that PHP arrays are not object means that they are not subject for lots of useful object features such as type hinting.
7. Overuse of Magic Methods:
Magic methods are useful at times, the constructor itself is actually a magic method, while others like __call() and __toString() are proven to be quite helpful for a program. However, a magic method takes at least 3x more time to execute compared to a standard method, they should only be used when necessary. Sometimes the presence of magic method also indicates that the class is not well-designed in the very first place.
8. Overuse of call_user_func_array():
First of all, I doubt call_user_func_array() itself is even considered OOP at all. But anyway, its commonly used to invoke an object's method with array of parameters. The problem with this callback function is that, its slow, its slower than a snail. Using __call() together with call_user_func_array() makes your program 17x slower, while its much faster to simply use variable method name such as $object->$method($arg, $arg2...).
9. Overuse of Method chaining:
Method chaining is a very interesting and convenient feature, it is inspired by smalltalk's cascade feature. Unfortunately, method chaining is not as good and powerful as smalltalk's cascade, and abusing method chaining can easily break encapsulation and introduce tight coupling(dependency) between methods. Id personally only use it for builder object(like a query builder) or setter methods.
10. Procedural code:
Need not to explain much on this one, the presence of procedural code is an implification that your code is not object oriented. What to do with it? Refactor, refactor and refactor, plain and simple.