Question

First off, I’ll admit that I’m anal about such things. (Bad, bad, me.) However, I’m just wondering what’s considered best practice in terms of naming PHP include files.

As a base case I’m going to keep .php as the final extension (to help prevent un-parsed files being fetched), but to aid distinguishing between a front end file and an include file I’m either going to:

1. Name all of the include files XXX.inc.php

2. Name generic (non class) files as above and class definitions as ClassName.class.php (Potentially handy for auto-loader utilisation down the line, although I’m not a big fan of auto loaders.)

I’m currently plumping for option 2, but I’m just wondering if there are any other suggestions or bits of advice you’d recommend.

Answer 1

First of all, I totally agree with you when you say that all PHP files should have “.php” as a final extension ; two reasons for that :

• as you stated, it helps prevent un-parsed files being fetched
• it also helps with IDE/editors that do syntax-coloration based on filename : you don’t have to configure it to consider “.inc” as a PHP file.

There are cases when I do otherwise, though ; the main reason for that is when I’m using a tool (CMS, Framerwork, library, …) that has some rules about naming of files : I tend to follow those, even if I don’t like them.

For instance :

• With Drupal, I use “.inc”, “.module”, “.install”, …
• With Zend Framework, I use “.phtml” for views scripts (HTML+PHP)

For files that contain classes, I don’t like “.class.php” : I think it’s kinda redundant ; I tend to use “MyClassName.php”, and use this for autoload.

(BTW, that’s what Frameworks like Zend Framework or Doctrine ORM recommend)

As a sidenote : you say you are not a big fan of autoloaders ; why ?

I use those as much as I can :

• generally better for performance : only the code you really use is loaded / parsed
• less code to write (no require/include)