Developer guideline¶

Philosophy and goal¶

The goal is to write a small fast and stable core code which is easy to extend. The priorities are as the following:

• Write OOP and clean in the given MVC structure
• Protect and secure the code
• The code should be fast and performant
• Focus on the core functions, and only as last thing, think about eyecandies and design.

Remember we dont want an ecommerce framework full of features. We want a slim and fast framework which can be easily extended with features.

• Mistakes might happen, important is to learn from them
• It is better to do something wrong than to do nothing

Guidelines for teamwork¶

The first very important rule is,

"Stay at your task"

This means, when you find a bug somewhere while you are working on your task, don't just fix it. Look in the tracker who is responsible for the code, look in the svn history to see who did the last change or even better the changes which cause your bugs. When you don't find any person ask the projectleader (Max Milbers). Give the person some time to correct the code, and fix it only when you get an OK by the projectleader.

This rule is very important for the teamwork and has several reasons.

It often happens that someone is changing something which is effecting the code in many areas. We already had the case that someone (lets call him A) changed the code. Another guy, B, was working on his own code, using code written by A. Due the changes the code of B didn't worked before and B started to "fix" the code of A, which just destroyed the work of A, because B thought in the old structure and A just invented a new system.
Or another annoying and frustrating case is when B says to A, hey there is a bug in your code. A starts immediatly fixing it, but B fixed it also and A gets an conflicted SVN (because B already fixed and comitted it) and did his working for nothing or even worse (we had that also), gets an conflicted svn and has to fix the "fix" of B again, because only A really understood that part of code.

So working in the svn together is quite easy even when we work on the same files, when everyone follows the rules:
- update your svn often
- stay at your task
- don't fix bugs not related to your task without permission by the projectleader.

Note about svn:
If you want to commit a new version, first do an update via SVN of it, then test it again and after that commit it.

Requesting features.¶

If you have an idea or special interest for VirtueMart, write it in the internal forums where we can discuss it and develop a plan. However, if you start developing something then finish it. Too often developers are very enthuastic and start a great, big, mega feature and end up with nothing useable. Discussion and planning in the forum should make it possible to work together.

Everyone can add features as many as he wants but must follow 3 rules
1. it must not slow down the page and/or can be disabled and is disabled as default
2. it must fit in the rest of the architecture
3. it must be bugfree for the release date (Beta, RC, Final)

https://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/

Some general coding advices¶

Here a guide for Setting up a Development Environment
Here are some general tips and tricks for php: general php hints
Here is a guide for writing code Coding standards and hints for Virtuemart
Here is a guide for GUI standard