@@ -45,22 +45,32 @@ If you find code that is not meeting the standards, we encourage you to improve
* Create a Jira issue for your coding standards improvements which is separate from any other code changes you happen to be making at the time.
* Isolate your coding standards improvements into commits which do not contain otherwise unrelated changes.
### Orange Light code
### Specific clean up tasks
Developers who are looking to contribute to this effort may want to
consider doing any amount self-contained work on the following areas:
Orange light code is code that has the feel that it is wrong and should be refactored. Developers who are looking to contribute to this effort may want to consider doing any amount self-contained work on the following code.
* Using joins on `civicrm_option_value` rather than using PseudoConstants - this has performance iplications
* Removing as much as possible passing by reference to functions.
* Increasing code complexity, this has two issues firstly it increase the fragility of the code and also makes it harder to test
* Where ever `$session = CRM_Core_Session(); $userid = $session->get('UserID');` or very similar these calls should be replaced with `CRM_Core_Session()->getLoggedInUser()`
* Clean up messy code, see if code can be refactored and moved into parent classes and make them more generic, Also elimiate any duplicate code
* Increase the usage of Doc blocks to help with auto generation of code
* Move more business logic out from the Froms and API if possible to the BAO level
* Remove eval() instances
* Develop & confirm standards listed above (incl decide on smarty coding templates, separation of tpl and js)
* Move business logic from the forms to the BAO
* Remove eval() instances
* Cleanup and centralize the token code.
* Code duplication should be addressed - e.g the introduction of a select function in CRM/Report/Form.php around 3.3 made identical functions in child classes obsolete. This is a good taks for someone wanting to learn
* Start auto-generating documentation for internal classes and prioritize the classes in most needs of doc/inline help - Start experimenting and migrating part of the core code towards Symfony2
* Eliminate duplicate code, move into functions
* Eliminate duplicate functions, move to parent classes
* Clean up messy code
* Look at repurposing the coder module to keep CiviCRM tidy
* Git rid of unused functions
* Look through the "todo" "fixme" and "hack" comments and see about fixing them
* As CiviCRM now requires PHP 5.3, modify code to use the Drupal 8 coding standard of using the PHP keyword const in place of define();
In CiviCRM we aim to compile SQL in the following order of preference
1. API - Predicatble well tested
3. DAO / BAO - `CRM_Core_DAO()->fetch()``CRM_Core_DAO->copyValues()`
2.`CRM_Utils_Select`
4. Compiled SQL
In CiviCRM we aim to use the APIs as much as possible as they have a solid test framework and a test contract behind them. This means if something is tested through the phpunit tests then it is on CiviCRM's responsiblity to ensure that does not break.
