###################################################################
 # squizlib - The Squiz General Source Library                     #
###################################################################
# URL: http://www.squiz.net/

This README file contains, or should contain, any information
necessary to understanding the structure and purpose of the
directory tree it resides within.

The Squiz General Source Library is an attempt to get some
organisation and efficiency into the way code is written, maintained
and reused within the company.

This code can range from PHP (which at the time of writing takes up
99% of it), Javascript, C++, Java, HTML, SQL, and any other
lanaguage we start to use.

HOWTO's and generic data (e.g. lists of country codes, currency
conversions, decimal places of pi) could also be stored here.

I will not define any standard for including source code in the
Library, since different contributions will require different
support. BUT...

A general philosophy is that any contribution to the Library
should:

	* Work. Don't add it until it is functional and tested.

	* Be generic. Code with sharing in mind, but you will have to
	  write client/job-specific code from time to time. Don't put
	  it in the Library if its of no use to anyone else.

	  If its *really* good and you just *have* to share it, write
	  a modified generic version. Flexibility is sexy.
	
	* Be modular. If the lanaguage you're writing in isn't OO,
	  that's no excuse. Hide the internals. Make a friendly
	  interface. OO is sexy.

	* Be compatible with other components. You should be familiar
	  with what else is in the Squiz Library. Write your
	  contributions not only so they work nicely with other
	  components of the library, but also have the same "feel" about
	  them. I.E. Use simliar terminology in varible names and so
	  on. Follow the coding standards (yet to be written at time of
	  writing). DON'T WRITE ANYTHING THAT WILL CONFLICT WITH ANYTHING
	  ELSE IN THE LIBRARY. You never know when someone might want to
	  use your "clean_string()" AND someone else's "clean_string()"
	  in their project. This is why classes/objects are important.

	* Be unique. Don't write another bulk-mailer if someone's already
	  written a perfectly good one. If the existing one isn't good
	  enough, develop it further. Keep it backwards compatible, but
	  add extra flexibility. If the existing one is utterly useless,
	  write a new one and call it something else. Then try to phase
	  the old one out of use. Anyway, just be sensible and not
	  pig-headed (I know its hard :).
	
	* Include instructions. Not only should these instructions
	  explain how to use your code, its interface, API etc; but it
	  should also contain instructions to future developers who may
	  want to expand on your code. Instructions can come in a number
	  of different forms:

		* Code comments. Vital to further development/maintainence.
		* Example usage - required in almost all cases.
		* User guide/manual - for large systems that have a UI.

	  These three forms of documentation provide for the future
	  developers, programmers using your component and end users
	  respectively.