Regardless of our current skill level, we all were beginners at one point in time. Making classic beginner mistakes comes with the territory. Today, we've asked a variety of Nettuts+ staff authors to chime in with their list of pitfalls and solutions - in a variety of languages. Learn from our mistakes; don't do these things!

The article starts off with some Javascript tips, but quickly gets into some more PHP specific things like:

• Use Ternary When Appropriate
• Use Guard Clauses
• Keep Methods Maintainable
• Avoid Deep Nesting
• Don't Overuse Variables

There's also two "extras" thrown in more concerning general programming practices - using methods to represent actions and some basic code readability suggestions.

Never trust user input! Injection is a threat . You are the new web developer, aren't you?. Never trust user input is the first rule I had to learn as a web developer in anchient times. Injection can happen whenever user input is interpreted or used to compose new data. A quick recap of the #3 mistake from todays Top 10 MySQL Tips and Mistakes for PHP Developers web presentation. A webinar recording should be available in a couple of days.

He points out a few "don't" things to avoid - like directly injecting superglobal values into your query and to remember that not all SQL injections are because of escaping issues. The real key? Validating input - be sure you're putting values into your query that are of the correct type and contain what you expect.

[Outdated tutorials and information is] one of the reasons why new PHP programmers are so frequently blamed for ugly, outdated, or insecure code. They can't help it if the first Google result was a four year old article teaching a five year old method! This document tries to address that. It's an attempt to compile a set of basic instructions for what can be considered best practices for common and confusing issues and tasks in PHP. If a low-level task has multiple and confusing approaches in PHP, it belongs here.

The site has sections for topics like:

• PHP & MySQL
• Single vs Double Quotes
• PHP regular expressions
• Validating emails
• Checking null and false values

If you're interested in helping out and adding more content to the site, contain the maintainer and let him know.

Inheritance offers a straightforward way to easily spawn a large number of objects that are semantically related to each other without having duplicate code. The concept is ridiculously simple - yet powerful: you first drop as much logic as possible within the boundaries of a base type (usually an abstract class, but it could be a concrete one), and then start deriving refined subtypes according to more specific requirements. [...] Not surprisingly, this repetitive encapsulation/derivation cycle lays down on the formalities of a design pattern known as Layer Supertype.

They describe the "supertype" as a replacement for an overly bloated domain-related model. Their example replaces a PostInterface/CommentInterface with a more generic "AbstractEntity" that handles some of the basics for you - getting/setting, checking a field, setting an ID and outputing the information to an array.

If you've been programming for awhile, then you've probably experienced your fair share of cryptic error messages. It's understandable that building in detailed error messages that are clear to even novice developers is not always a high priority for programming languages when there are so many other features to create and issues to address. The PHP language has decent error messages, but it is by no means an exception to this rule.

The three errors he covers are probably familiar to anyone that's been working with PHP for any length of time:

• Fatal error: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
• Fatal error: Can't use function return value in write context
• Fatal error: Exception thrown without a stack frame in Unknown on line 0

For designers, Symfony2 has been a welcome change from those old flat PHP files. Twig is beautiful, the framework separates the code from the layout, and we no longer have to find our way through lines of PHP code. But if you are a designer working on a symfony project for the first time, these are a few tips that can help you get up and running quickly.

The four common problems they've seen are:

• How do I disable the toolbar at the bottom of the page?
• Errors about missing libraries/files
• No Javascript or no-css showing up
• A completely blank page

Every PHP framework has it's own unique set of interfaces for common operations such as logging, caching, http clients, filtering, validation, etc. This creates a situation where a framework tends to be loosely coupled but only within the scope of its own interfaces. [...] Loose coupling is therefore a bad joke. It is a narrowly defined concept usually described within the scope of one particular application. We never really apply the concept across multiple applications written with different frameworks because, at that point, the disparate interfaces of both frameworks would immediately make loose coupling unobtainable.

He goes on to talk about a simple example, ZendFeedReader, and how it's very difficult to swap something as simple as the HTTP client out for one from another framework. He mentions the common scapegoat for over-interfacing - Java - and how PHP's is a bit more "practical and flexible" in that department (a good and bad thing).

So yes, common interfaces would benefit PHP and would make framework libraries more interoperable and thus usable within competing frameworks. Hey, if you can't beat them at least make sure you can inject your classes into them. Hmm, still sounds dirty.

The PHP community was reacting to Lukas Smith's "Interfacing the PHP world" for most of last weekend. [...] It's a pretty major propositon to start 'interfacing the PHP' world. Catch up on the conversation and let us know what you think.

Mitchell summarizes Lukas' thoughts into three points - interfaces in separate repositories, PHP frameworks not adopting 5.3 yet and the customization of method names/naming conventions across frameworks and tools. Another response to Lukas came from Herman Radtke with Lukas following up his original post with "Why Bother?"

In my previous blog post I was brainstorming the possibility of collaboration between various frameworks to define a set of common interfaces. But I kind of failed to explain why this would be useful. Herman's "rebuttal" made this omission on my part quite clear. [...] That being said the open questions left in my previous blog might still prevent this idea to take off, even if I manage to convince the general community that the above mentioned negative effects are not such a significant concern.

He talks first about some of the things he sees PHP as having done right (citing its popularity) and contrasts it to Java based on the standards they impose. He goes on to mention how interfaces, introduced early enough in the process, can help with the "best tool for the job" idea (with an example involving Symfony2, Zend Framework and Doctrine).

Despite the high expectations placed on them at times, developers are human. They were the last time we checked anyways. As humans, we are bound to make mistakes from time to time. And simple, common mistakes often slip past our filters the more comfortable we become with something. [...] But knowing what these common mistakes are and how to avoid them can really help speed up the development process and keep our clients smiling.

His list includes three big ones that, if forgotten, could end up being detrimental to your application (sooner or later) - poor housekeeping/organization of code, forgetting punctuation and forgetting to validate input from users.