views:

799

answers:

3

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.

+3  A: 

I use 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.

chaos
I normally use `.inc` files for static HTML that will be included. So, `login.inc`
Chacha102
If you look at the many frameworks out there, if you have a folder for your classes, there is no need to put a .class.php in there. On the other hand, if you have just an "app" folder with all your files, then maybe, but i'd just say rethink your folder structure.
Garrett
Like the .lib.php idea and totally agree with the rationale behind not using XXX.inc.php - this is probably why it doesn't feel 'right' to me.
middaparka
A: 

I like to only have on entrance point to my php application(index.php) so I already know that all the files are going to be included.

ajcates
+2  A: 

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 redondant ; 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 of autoloader ; why ?
I use those as much as I can :

  • generally better for performances : only the code you really use is loaded / parsed
  • less code to write (no require/include)
Pascal MARTIN
I'm generally not a fan of auto-loaders as they aren't as explicit as a manual include. (In my mind it's somewhat equivalent to explict declaration of a variable.) That said, I realise it's the way things are going and that the resource overhead is largely irrelevant these days.
middaparka
We agree one one thing : it's not as explicit as manual include :-) (At least, when classnames are known at the time of writing code)
Pascal MARTIN