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:
Name all of the include files XXX.inc.php
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.
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
ClassName.class.php for class files and
SomeDescription.lib.php for non-class files.
Not a fan of
.inc.php. Seems somehow wrong to describe the file in terms of how it may possibly be imported, instead of its content.