ok, so fygar and i were talking, and he wants to learn php, and i thought that the easiest way to learn was to look at code, rip it apart, and put it back together, and then since chris had his genious idea of php tennis, i thought that would be a good way to get fygar introduced to php, so, can we start something?

*Nods excessivley*

Sure, I'll add a tennis forum when I get to school in a bit...

It'll be open for PHP Tennis, Photoshop Tennis, and whatever other languages people want.

I think the best way to do the PHP tennis is to write the code, zip it, then upload it to your posts via an attachment... but if you have a better way, let me know... the reason I say zip it is because if there are multiple files, it'll be easier to download a zip than from a bunch of posts.

just because I think it would be helpful for anyone taking part, or just reading up on php, here's a little advice for everyone

1. lay out your code neatly and readably, there are various different guidlines to doing this which often disagree, but my opinion is that if the code is easy to read then it doesn't matter exactly how you've layed it out.

2. when reading code, it helps huge amounts to have an editor that highlights text, I use Crimson editor which is free and very good, and there are others around.

I'm a little confused as to what this 'tenis' deal is all about?

Crimson Rules.

as far as the readiblity of code is concerned i think there should be comments and the code should be tabbed...that's usually what makes it easiest, and as far as an editor is concerned, may i suggest editplus

Might I be so bold as to post a few suggestions on code and tennis in general:

1) Do you want to play snippet tennis or do you want to build real applications/modules? If it's the later (which I thought was the direction the origional tennis thread took) then you need some kind of approval system before code gets released (what if I make changes and they are worse than the origional or have bugs).

2) A generic documentation system (i.e. perl has pod) so that any modules/code you write playing tennis will have complete documentation embeded with the code. Or a DTD so you can write documentation as XML (in a seperate file) that can be read by a generic parser (it sounds way more complicated than it is). This may not sound important but if you plan to build "real" applications rather than just playing tennis with snippets of code as I have seen on other sites this will come in handy.

3) A utility for storing/archiving/searching/downloading applications and modules (like the CPAN). To do this it would be ideal if (2) had been written as you can read documentation before you download (this should give you an idea of features, version history, methods and functions).

4) A version control system, make sure the variabes $VERSION and $UPDATE are global and at the top of every application, so you dont play tennis with old code.

5) Debugging and Benchmarking modules. Rather than add more functionality dont be afraid to rewrite someones code better, benchmark it, then add in temporary documentation to say why you made the changes. Not that the old code is just plain 'wrong' just that you might know a better way.

6) There is no reason you cant have more than one tennis match going at a time so if the above sounds too complicated for you, start another tennis project with less lofty goals.