TRINIX

With this topic I’m going to write down some useful tips when you want to start professional development and/or start working in a development team.

When going pro there are a few issues you always have to keep in my mind.

Your project should be:

• easy to manage
• comprehensible by out-side developers
• build logical
• structured
• well documented & commented
• set-up naming & coding standards

Structure
When building web applications you get a lot of files of all kinds (CSS, PHP, Classes, JS,…)
It’s important to keep a clean structure. There could also be a difference between a public and a secured interface. So I advice to setup your directory structure in the following manner.

WEB_APP
===|——— gui
===|=======|——- js
===|=======|——- css
===|=======|——- icons /images
===|=======|——- rss
===|=======|——- config
===|=======|——- tpl
===|=======|——- class
===|=======|——- modules
===|=======|——- export
===|=======|——- service
===|——— system
===|=======|——- js
===|=======|——- icons /images
===|=======|——- css
===|=======|——- config
===|=======|——- tpl
===|=======|——- class
===|=======|——- modules

We work in a multi-tier manner. This means that we try to separate the visual,coding and database. Our web application consist out of 2 big parts, gui and system. The gui stands for the public part and system consists out the secured admin section. Of course there can be more parts needed, this is just an example case structure, which I consider a good start for a basic web app.

Explanation of directories:

• js:contains all javascript libraries
• icons / images: contains all necessary images and icons needed by the gui
• css: contains all style sheets
• rss: is the public rss feeds directory
• config: here are all configuration files placed, like your DB login data, general application settings, … files that need to be included in every page
• tpl: we work in a multi-tier environment, the tpl directory keeps the HTML templates (the pure visual part)
• class: contains all general classes, like the DB class, the HTML email class, …
• modules: consist out of all the specific application written modules, divided in directory per module.
• export: contains all the possible export files of the application
• service: is the web service part, here you place all the code for your web services.

This is just a simple case, but I find the structure clear and easy to expand.

Coding & Naming Conventions
When building applications or work in a team. You should definitely need to have this. The coding and naming conventions are the rules to follow while programming, more specific for the usage of file and directory naming and the manner variables,functions and classes our declared. This prevents each programmer of using his own specific manner of writing code and so afterwards really difficult for other developers to understand his code. And let’s say one year later the programmer still understand his own code and still works in the same way.

1. Directories

• Short names
• All in lowercase, no studly caps
• Prevent usage of points (.) and spaces
• More then 1 word use underscore (_)
• For related content use a prefix with an underscore. (ext_dir1, ext_dir2,…)

2. Files

• Logical names
• All in lowercase, no studly caps
• Prevent usage of points (.) and spaces
• Function specific files (class,func,…), use prefix followed by an point (.) (class.name.php, func.name.php)
• More then 1 word use underscore (_)
• For related content use a prefix with an underscore (adm_file1, adm_file2,…)

3. Coding Standards
Here for I would like to refer to the PEAR Coding Standards (http://pear.php.net/manual/en/standards.php)

Documentation
Another important step in becoming a pro developer is to learn to document EVERYTHING.
Write down your Application sturcture and explain what and why.
Also write down your Coding & Naming Conventions.
Everything you do or use, explain in documentation how, what, why.
This seems a waste of time but if you have a lot of projects and you need to expand an older project you can simply read your documentation and you know the structure of your application without having to figure everything out again.
Another plus is to pass your project on to another developer, you wont feel like an help desk if he don’t email you every 5 min for info over the project. Because you can just give him all the docs and he can start reading reducing the number of question greatly.