Treb - A simple framework for PHP

Introducing: Treb – A simple framework for PHP

http://eliw.wordpress.com/2012/08/31/introducing-treb-a-simple-framework-for-php/

Object Scoping

http://blog.ircmaxell.com/2012/08/object-scoping-triste-against-service.html

Validating Emails in PHP

A very quick snippet today because I've told two people to use this approach in the last few days and both of them told me they didn't know about it. How to check if an email address is valid in PHP: use one of the Filter functions, like this:

 
$email1 = "nonsense.something@dottiness";  // not a valid email
$email2 = "dotty@something.whatever";  // valid email
 
$clean_email1 = filter_var($email1, FILTER_VALIDATE_EMAIL); // $clean_email1 = false
$clean_email2 = filter_var($email2, FILTER_VALIDATE_EMAIL); // $clean_email2 = dotty@something.whatever

The Filter extension was new in PHP 5.2, but is one of the unsung heroes of the language. It's rare for me to ever describe one approach as the "right" way to do something - but for validating data, Filter really is excellent, offering both validating and sanitising filters and generally making it super-easy to clean up incoming variables. Many of the frameworks offer equivalents, and I'm sure many of those are wrapping this too.

http://www.lornajane.net/posts/2012/validating-email-addresses-in-php

Are PHP Developers functophobic?

I do feel this is the way things are going, although it seems they may already be this way!..

http://nikic.github.com/2012/08/10/Are-PHP-developers-functophobic.html

Coding Standards

I've recently come across http://pear.php.net/manual/en/standards.php, which got a few ideas jumping about my head, and reminded me of a tool I use from time to time for curiosity purposes more than anything - phpcs or PHP CodeSniffer (http://pear.php.net/package/PHP_CodeSniffer/).

I occasionally run phpcs against some of the codebases I work on, just to see if there seems to be any structure or standard being followed throughout the system. The results are usually verbose and stressful to even begin trying to fix, and sometimes wonder if coding standards are used effectively anywhere.

With the many techniques and ways of completing a task in PHP and with PHP developers becoming more and more OOP oriented, developers are beginning to play around with inheritance and abstraction, namespaces and interfaces, getters and setters - All the buzzwords and terms which lead to more and more overly complex code for no reason other than - "we used all of the above", and as a result "our code must be cutting edge".

But the issue here comes at the cost of maintenance. I guess this can be classed as Technical Debt and it isn't necessarily the fault of the developer either.

In some cases developers may walk into a team where no standards are currently in place, and it is up to that developer to set a standard. Some developers will be happy to struggle along and hack and slash code until it works and leave satisfied at that, but there will come a point when they suddenly realise a standard is the way forward. But what should a general coding standard cover?

I definitely don't think a coding standard document should be hundreds of pages long, however I definitely don't think it should be a couple of sentences. Somewhere in the middle I guess is between 8 and 10 pages. Just long enough to set the foundations for new developers, and not to long to lose them that they wonder what they're walking into.

I think a common coding standard should cover 6 key issues:

1.  Naming Conventions
2.  File Naming and Organization
3.  Formatting and Indentation
4.  Comments and Documentation
5.  Classes, Functions and Interfaces
6.  Testing

Each of these, I'll discuss in a few lines.

1. Naming Conventions
Naming conventions here should cover pretty general variable naming standards. Although some of the standard may be obvious to programmers of say C or Java, as they would be used to explicitly declaring the scope of their variables, it might be good practise to adopt a similar standard even within PHP where things are a little more flexible. For example, would you like string variables to be prefixed with str (strName), or integer values to be prefixed by int(intAge). Should variables be all lowercase with underscores(str_name) to separate "words", or camelcase (strFirstName) to represent new words?

2. File naming and organisation
File naming and organising should specify how files are named, and the folder structure they should follow. For example, are all your class files in a folder called classes, or a sub folder structure application/core/classes. Or are your files grouped into modules, and within these modules, a classes folder exists. Where do images go? Both structural and customer uploaded content if applicable? Would you rather everything was above the public_html directory, and accessed through a controller file? specify this site and file organisation at this point.

3. Formatting and Indentation
Some developers swear by tabs, some swear by 4 spaces. Some just want to cram as much as possible on one line! Decide on a standard that you would like everyone to follow that is easy to read and maintain. If developers are using different IDE's, tabs might not be a good idea, as some IDE's have different indents for tabs, whereas 4 (or 6 or 8 whatever you like), spaces are pretty easy to replicate no matter what IDE is used.

4. Comments and Documentation
I remember this from as far back as High School - "Documentation, documentation, documentation". The envy of my computing life, but now I'm in the real world, how wrong I was to hate it. If I could have documentation for every piece of code I've used it would be amazing. Bottom line here, developers don't like documenting, but if you set this in your standard, to at least document the purpose of classes or files in the header (I'm thinking in phpDoc style here), and comment complex pieces of code, using a certain comment style, this will go down well if developers can see this across other code they'll be more inclined to follow suit.

5. Classes, Functions and Interfaces
A standard here, could be that concrete classes are never passed into an objects, and every class must implement an interface. How your classes are named and how methods are named should also fall under this category, for example, class names should always be capitalised and singular (eg Cart or Post), and all methods should be private except getters and setter which are prefixed with 'get' or 'set', and camelcased (eg getPostTitle(); or setDeliveryCharge();)

6. Testing
How is your code tested? Do you have a test suite that is run on check in, or do you manually write tests for your methods as and when you create the methods, showing inputs and outputs. A lot of organisations these days are moving towards CI (Continuous Integration) solutions where test suites are automatically ran (a blog-post I'm looking forward to writing). Some have unit or functional tests which are manually ran before code is checked into a repository, or some just look at the code and go 'ok, yeah that works'. The latter of which many of us have been pretty good at in the past. You may also have a QA team, person or phase of development to go through and sign off checklists before work is passed back to the client, whatever method works for you, document it and make sure everyone does the same.

Crikey, I haven't half went on there! Thank you if you're still with me. The bottom line I guess is, are coding standards a good thing or a waste of time and money? I believe they are a good thing. If implemented correctly, they should set the foundations for any new developers joining your team, and maintaining the highest standards of code quality. It also leads on to maintenance, that if a piece of work is being picked up by another team, they're not completely in the dark, they know if a variable is all in capitals its a constant defined in the configuration file, and this configuration file is always in the same place on every project. Also, if they're working on a specific area, they know to checkout unit tests or certain areas of documentation for details on that area of code.

Thanks for reading.

include, require, include_once or require_once

Well the question Today is which is the best or correct one to use?

There are a few reasons to choose between include and require I suppose, based on the importance of the file you are 'including'.  If I was including a config or settings files with critical information in it, or a bootstrap loader file which all my files need, I'd be inclined to use require over include - as the file is Required, and not an optional file that the site can load without.  Take on the other hand if I was pulling in a file with some adverts on it, or a banner on the site from another template file, I'd be more inclined to use include, as this isn't mission critical to the site loading - Ok I'd really like it there, but if there is an issue for whatever reason, I still want the rest of the page to continue loading.

Next comes the question of include/require vs include_once/require_once.
I guess the age old discussion of performance comes to mind, if I know for a fact (and I should It's my project), that the file I'm pulling in is only to be read in once, even still I shouldn't have to use *_once statements, however if for whatever reason I decide I do, as far as I'm aware, the process of calling:

require_once 'require_me.inc.php';

The system is going to go:

• Ok, we require this file 'require_me.inc.php'
• has it been required already? Let's check..
• [check previous list of required files in this execution]
• if it has been, don't include it again
• [continue script]

If I choose to just require it:

require 'require_me.inc.php';

The system should go:

1. Ok we require this file 'require_me.inc.php'
2. pull it in now
3. [continue script]

OK, now that process takes microseconds (if not faster), on server set ups these days, but scale this up to a situation where you may have mega numbers of files included, is this going to cause performance issues?  I'm not sure, would be interesting to benchmark the exact differences in performance of the commands, and I might in fact do that someday - just not today.

If anyone is prepared to benchmark these statements for me, it would be interested to see.

Also, you may have noticed that the code snippets above I used require 'file.php'; as opposed to require('file.php');  This is because I believe include and require are statements as opposed to methods which one passes variables into.   in the same way I'd call new MyClass(); as opposed to new(MyClass());

Thanks for reading.

Portable PHPUnit

So looking into PHPUnit again this morning, and would be great to have a "portable" set up.  The usual way to set up PHPUnit is to install the PEAR package.  However it turns out it is possible to have a more portable set up which can be moved between my XAMPP usb pen, WAMP laptop setup and LAMP stack at work, without all needing to have PHPUnit installed under all the separate hosting accounts.

Found this post the other day: http://stackoverflow.com/questions/4801183/php-is-there-a-portable-version-of-phpunit.  Well in actual fact I found the process on another site, but that one sums it up pretty well I think.  And I don't think you'd need to use the git clone's either, you could I suppose download the source from github in an archive and extract it.
The main thing to remember is to update your include_path() to include all the paths to the modules you've downloaded though.

I will have to have a play around with this, as I have PHPUnit PEAR packages all installed on my localhost already, but am keen to have a portable solution.

Me and TDD

OK, so I'm looking into Test Driven Development (TDD).

Now, I've looked into working with it before within the PHP environment I use daily, but sometimes feel a bit overwhelmed by it all.
Every time I read up about it, I always get a different slant on things, and always learn something different or new from the time before, and feel I am getting to grips with the basic principles now.

The big question is whether to start from scratch or attempt to write tests for the existing codebases I have.

I have a personal codebase, albeit pretty dated, and then there are the (many) styles and codebases used at work for me to choose from.  Part of the dilema is if I use any work code, I can't post it online or use it in my own work, although, to be honest, when work finishes, usually the last thing I want to do is come home and be glued to the laptop writing code.  So that explains why I haven't made much progress over the past 3 years, and from time to time dip into blog articles and posts on TDD and Unit Testing.

Whether to use PHPUnit or Simpletest, whether to use a framework or not, and if I do use a framework, most of these have testing classes and modules integrated with them.

Along with beginning to look into TDD, a lot of the examples I am finding at for calculator and string classes, and very specific to testing the logic of these classes.  When I think about applying these to the monolithic grouping of php files and classes that comprise bespoke and custom built ecommerce and cms systems, I suddenly become overwhelmed by the sheer amount of code I'm going to have to write.  I mean, OK, I can write a unit test to verify an add() method works correctly and returns all the expected results given this input and that input, and throws exceptions or whatever.  But what about scaling that up to handle items with stock levels, sizes and prices that can all change, mixed in with a checkout or buying process, and whether an order was successfully completed.  Including discounts and shipping costs and members being logged in and all sorts - it just blows my mind trying to wrap all that up in tests.

I guess the key is to do it little bits at a time.  Focus on possibly a member, then items, and the process of building basket, then the ordering process, then the checkout and confirm stages.  Tying that all in with a database, and trying not to make too drastic a change that I may as well have rewritten it from scratch isn't easy.

So, it continues, my research into Unit Testing and TDD, and Acceptance Testing and ATDD.  I am leaning towards PHPUnit, but when I start to think about Mocks and Stubs to isolate the tests, I feel I'm going to end up writing so so much more code trying to refactor my existing codebase, that I keep leaning towards a re-write!

And why I don't just do it... time I guess, when customers need a feature, they want it now, and they want to pay for that feature, not me going back and rewriting the existing system.

I would love to write more posts about my journey into actually beginning to follow TDD a lot more strictly, but I don't think that will happen today.  Although, it might!

Comments welcome :)