Channels ▼

Web Development

What PHP Programmers Can Learn from Ruby on Rails

Although PHP and Ruby on Rails are used for similar purposes, their online reputations are miles apart. Ruby is often referred to as a beautiful language, while PHP is sometimes dismissed as a haven for bad code or as a language for beginners. While there is some truth in all these observations, a casual job search still shows more open jobs for PHP developers than Rails developers, and many of the largest sites on the Internet use PHP (at least partially) as their back-end.

PHP isn't going away anytime soon, and the best way to help patch its spotty reputation is to encourage quality code and proper practices. As a self-defined PHP developer who has dabbled in Rails for a few projects, here are some things I think PHP developers (especially those still in the process of learning PHP) can crib from Rails.


In Rails, there is almost always an established "correct" way to do something. From naming your models and controllers to form validation, Rails developers tend to have a set of best practices and stick to them. They often refer to these practices as "The Rails Way." Following "The Rails Way" is not required, but doing so makes code easier to read, and offers the developer a lot of default behavior they can work with. A Rails developer who is trying something for the first time can often "guess" the right way to do it because the conventions of Rails are logical and easy to follow.

In PHP, convention is much more difficult. Even some built-in PHP functions don't follow convention. There have been attempts to define standards for PHP, including the PSR style recommendations. You can choose to follow one of these standards, but at the very least, you need to make sure your own code is consistent. Decide how you want to format your files. Figure out how you are going to connect to the database and do it the same way every time. Even better, get together with your coworkers and make some decisions. Two hours spent drafting a "best practices" document for your company will save countless hours down the road.

Cohesive Web App

A Rails project is more than just files full of code. A Rails project can include many parts, including a connection to a repository, the database, data migrations, and information for development, testing, and production servers. These pieces are part of the full app and should all be considered as important as the code itself.

Many PHP programmers began in the simplest of ways. They learned by creating files full of code and copying them to a server. Far too often, this generated that work great now, but have not been prepared for the future. As requirements change, new pieces are bolted onto the project, resulting in spaghetti code, one-off pieces, and other development headaches. The best way to combat such a situation is to take a page from Rails and plan ahead. Think about each section of the project ahead of time. Make a plan, rather than just settling for code that works.

Code Reuse

All developers reuse code. Whether they are just copying and pasting from other files, searching online for code snippets, or creating classes that can be shared between projects, we all do it. Ruby on Rails takes code reuse a step further with the gem system. Gems are packages of Ruby code specifically designed to be shared with any Ruby project. Even Rails itself is technically a gem. Gems are made to be shared, to work universally. They are versioned, so that you can be sure of exactly how a certain version of a gem will function.

PHP doesn't have gems, obviously, but there are options. You could create your own set of loosely coupled, self-contained classes and use them in your projects. But why only reuse your own code, when you can reuse well-tested code from others? There are package and dependency managers for PHP that let you do just that Composer is a PHP dependency manager that allows you to include thousands of tested and packaged code snippets in your project. It keeps track of which packages depend on other packages and makes sure you always have the proper versions of the code you need. You'll never have to rewrite a database interface again.


Every time a new Rails application is created, folders for testing code are created as well. Every time you generate a new set of CRUD functionality, basic code for unit tests is also created. In Rails, testing is just part of what you do. You can ignore it if you want, but Rails is set up to make it easy to keep your tests up to date. This is part of taking the long-term view. The better your tests are, the less likely it is that bugs sneak through your testing process.

PHP has many options for testing, but since they aren't built into PHP the same way that tests are built into Rails, not everyone uses them. One option is PHPUnit, which allows you to create unit tests to ensure code isn't broken as changes are made. It can be combined with a functional testing tool like Selenium, which automates functional tests, attempting to test the application in the same ways that a user would. Testing is often overlooked as busy developers try to churn out features and fixes as quickly as possible. It takes dedication and commitment to follow Rails' lead and ensure that testing is made a priority instead of listed as something that will get done "when we have some extra time."


Namespaces are a way to keep code from colliding with other code. Especially if you are going to be using a lot of other people's code, utilizing namespaces helps keep any other code from interfering with your own. In Rails, namespaces are often used to keep different sections of an application separate. For example, an app might have an administration section, a client section, and a public section. Namespaces can help differentiate these sections of the site. You may want different code to be run when an Admin logs in, as opposed to when a client logs in, and namespaces can distinguish these separate login functions.

In PHP, namespaces seem appear to be pretty new. They were introduced in PHP 5.3, and the current version is only PHP 5.5. That said, PHP 5.3 was released more than four years ago! This is certainly a feature that PHP developers should be using at this point, especially when planning large projects or projects that will be using extensive third-party code.


As I mentioned, Rails is a framework that sits on top of the programming language Ruby. This is the best and most important lesson that Rails can teach PHP programmers: Use a framework. On any project that is large enough to be planned ahead of time, the idea of using a framework should be explored. Many of the best PHP frameworks incorporate all of the suggestions listed here.

Modern PHP frameworks run the gamut from full-stack frameworks that insist you to follow all their code practices, to minimalist frameworks that are nothing more than a few files enabling MVC, routing, and database connectivity. Find the best framework for you and your project. A quick Google search will show plenty of articles proffering which framework is perfect for your next project.

I once had a coworker who hand-coded every line of his projects. He refused to use anyone else's code. Although he knew the code for his project inside and out, his productivity was seriously hindered by this restriction. Instead of following his path, I recommend you trust your fellow developers. There are a lot of talented and smart people writing PHP code, and despite what some may say, PHP is not dead or going away anytime soon — so program accordingly. Ten years from now, when a brand new developer is trying to debug your code, he will thank you.

Jason Chandler is a senior Web developer at TopTenReviews and is instrumental in the development of review infrastructure.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Dr. Dobb's TV