Developer guideline » History » Revision 12
Revision 11 (Oscar van Eijk, 09/22/2010 04:19 PM) → Revision 12/17 (Max Milbers, 02/25/2011 04:42 PM)
h1. Developer guideline h2. 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 Guiding ideas and 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 h2. 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, dont 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 dont find any person ask the projectleader (Max Milbers). Give the person some time to correct the code, 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 guym, B, was working on his own code, using code written by A. Due the changes the code of B didnt 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 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 understoods 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 - dont fix bugs not related to your task without permission by the projectleader. Note about svn: If you want to committ a new version, first do an update via SVN of it, then test it again and after that committ it. h2. 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 possible to work together Everyone can add features as many as he wants but must follow 3 rules 1. - If you want to committ a new version, first do an update via SVN of it, then test it must not slow down the page and/or can be disabled again and after that committ it. Some minor bugs will happen but ensure that the standard system itself is disabled 2. it must fit in workable. Within the rest alpha phase of each release you do not need to spend too much time debugging echoes or things like this. Some examples: It might happen that someone is developing a great new view for the architecture 3. administration backend and committs a code that leads to a buggy panel that is impossible to use. Every developer of the team has then problems to develop further. Or if you change a database field to the new standards than it must be bugfree for the release date (Beta, RC, Final) is important to find it everywhere as best as possible. In other case other devs get crazy by mysterious bugs. - Mistakes might happen, important is to learn from them - It is better to do something wrong than to do nothing h2. Some general coding advices In general we avoid the use of globals. Globals are hard to maintain and they are unsure variables. Here a guide for [[Setting up a Development Environment]] Here are some general tips and tricks for php: [[general php hints]] h2. Code Formatting: We follow the joomla standard in most cases. We use camelCase for methods. For faster copypasting and working with database fields. Both variable and database fields are lowercase and seperated with "_". You may use for internal variables camelCase also. Example: <pre> function exampleMethod($data = 0) { if (!$product_id) $product_id = JRequest::getInt('product_id', 0); if ($product_id > 0) { ...; } } </pre> h2. SQL Formatting: The queries should follow this format: @$q = 'SELECT `example_id` FROM `#__vm_table` WHERE `user_id`=' . (int)$user_id;@ or if the $user_id is an array, use $user_id["myId"] Placing of the ` improves speed, because the sql-engine can parse faster ( and do not have to reparse). h2. Variable Formatting: Due abstract logic many people name their variables or database fields just "id", "key", "value" and so on. In our case we want to rewrite the structure of an old code, therefore it is very important to find the variable in the code rather fields in the database. So we want a kind of this: <classname><tablename>variable like here $vendor_id or $payment_method_id Exception from this rule is the use of ordering and published. Ordering and published with 0 and 1 as values are useable with the joomla standard methods. h2. Filename Formatting: Filenames should be lowercase. Models filenames (mymodel.php), view direcorynames (myview), all helper files and probably all other files loaded by the Joomla Framework, must be lowercase, no matter how you load the file: @$this->loadHelper('adminMenu'); // looks for the file helpers/adminmenu.php@ More complex filenames that are specific to your task and loaded by your own code (using require_once()), e.g. mySpecificClass.php, can be camelcase. Read this article for more info http://docs.joomla.org/Talk:Developing_a_Model-View-Controller_Component_-_Part_1#Use_lowercase_file_and_folder_names_in_your_components.21 h2. Table names Depending on the way mysqld is configured, the MySQL server might be case sensitive on linux systems too, so _always_ use the correct case, preferably lowercase only. h2. URL Requests: As written in the section __Filename Formatting__ above, Joomla requires lowercase filenames. However, URL requests are not lowercased by Joomla. In order to find the proper views and controllers, make sure you use lowercase only in requests, e.g.: $this->setRedirect('index.php?option=com_virtuemart&view=updatesMigration', $msg); // Fails $this->setRedirect('index.php?option=com_virtuemart&view=updatesmigration', $msg); // Works h2. Character Encoding: Like in joomla we use UTF-8. Please ensure the right character set in your IDE.