Symphony.

Over the last couple of days bauhouse posted some information about Symphony's file structure . I think this is really helpful but it raises the question how code should be structured and documented. Now that Symphony 2 is open source more people will start contributing: What are the guidelines, the dos and don'ts, the best practices? Is the extension API finished or does it need some polishment?

I'm not a PHP programmer, but I started working on an image field extension and have found it very hard to understand the inner workings of the system, as there is no information in the files themselves regarding what they are needed for. Especially when I look at the different fields and field extensions there seem to be some inconsistencies in function naming and the usage of ids and handles for saving entry data.

How could these things be organised?

Is the extension API finished or does it need some polishment?

I don't think the extension API will ever be finished, but our guideline for S2 is that all future changes should be backwards-compatible. So you could say it's finished in some sense.

there is no information in the files themselves regarding what they are needed for

Our omissions and lack of better organisation here is just due to lack of time to improve these things. In the near future, we plan to make one or more template extensions to function as an SDK and tutorial for extension developers. These should answer your questions about best practices.

For the moment, I'd recommend that where extensions differ, take your lead from the most recent one.