I might get voted down for this, but if you really do want to write your own framework, I say go for it because you will learn a lot from the experience. The other frameworks mentioned here are great and tested and you wouldn't be making a bad decision using them, but it's your choice.
Before starting to write your framework, look at the other frameworks (at their syntax, directory structure, naming schema, design patterns, etc) and try to figure out why they did what they did and what, if anything, you would do differently. Try out a few tutorials and play with their code, make a few sample apps. If, after doing that, you don't like using them, then go ahead and start planning your framework, keeping what worked and improving what didn't.
If you do decide to roll your own, here are a few things I would recommend from my own experience:
- Make Security Your Top Priority - If
you write a data access layer, use
bound parameters. If you write a form
class, guard against CSRF and XSS.
Catch your exceptions and handle your
errors. Make sure that your PHP
environment is secure. Don't try
coming up with your own encryption
algorithm. If you don't concentrate
on security, it's not worth writing
your own framework.
- Comment Your Code - You will need
comments to help you remember how
your code works after a while. I
usually find that docblock comments
are more than enough. Beyond that,
comment why you did something, not
what you did. If you need to explain
what, you may want to refactor.
- Single Responsibility Classes and
Methods - Most of your classes and
methods should do one thing and only
one thing. Especially watch out for
this with the database - Your
pagination class shouldn't rely on
your data access object, nor should
almost any other (low-level) class.
- Unit Test - If each of your methods
does only one thing, it should be far
easier to test them and it will
result in better code. Write the test
first, then the code to pass the
test. This will also give you greater
freedom to refactor later on without
breaking something.
- Abstract Similar Classes - If you
have more than one class that does
similar things, create a parent class
that uses the similarities between
the classes and extend it.
- Delegate and Modularize - If you're
writing a validation system (and
chances are you probably would),
don't include each validator as a
method in some super validation
class. Separate them into individual
classes and call them as needed. This
can be applied in many areas:
filters, languages, algorithms,
validators, and so on.
- Protect and Privatize - In most
cases, it's better to use getter and
setter methods rather than allowing
direct access to class variables.
- Consistent API - If you have a
render() method and a draw() method
that do the same things in different
classes, pick one and go with it
across all classes. Keep the order of
the parameters the same for methods
that use the same parameters. A consistent API is an easier API.
- Remember Autoloading - The class
names can get a little clunky and
long, but the way Zend names the
classes and organizes the directories
makes autoloading a lot easier. Update: As of PHP 5.3, you should begin using namespaces.
- Never echo or print anything - Give
it as a return value and let the user
decide if it should be echoed. A lot
of times you'll use the return value
as a parameter for another method.
- Don't Try to Solve the World's
Problems - Solve your own first. If
you don't need a feature right now,
like a class for localizing numbers
or dates or currency, don't write it.
Wait until you need it.
- Don't Preoptimize - Build a few
simple applications with your
framework before fine tuning it.
Otherwise, you can spend a lot of
time on nothing productive.
- Use Source Control - If you spend
countless hours creating a
masterpiece, don't risk it getting
lost.