Additional Coding Guidelines

1 Requirements

This guideline suggests to streamline the coding standards in ILIAS and make it easier for new developers to get involvend with ILIAS-Development. We'll provide several parts of the guidlines (such as Naming, Structure, ...).
The guidlines are currently written in german and as a open Google Drive Document which allows comments. Please review the document and add your comments and your change requests in the document. We'll collect those and put a summary to this page.

April 08, 2013
The following chapters are ready for discussion:

• Formating
• Naming
• Structuring of Classes

https://docs.google.com/document/d/1kCQDPzq7lVbdXeTdO3wGNM3L6atmGRQK0auxbS52Q1o/edit?usp=sharing

2 Status

• Scheduled for: Not scheduled yet (will be set by Jour Fixe)
• Funding: Required / Partly funded by / Funded by ... (please indicate if you have funding for feature)
• Maintainer: (will be set by Jour Fixe)
• Implementation of the feature is done by (company, developer)
• Contract settled: (fill in "Yes" if a contract is already settled, otherwise "No" )
• Tested by / status: (name, e-mail), (status information set after implementation)

3 Additional Information

Contact the following persons if you want to know more about this feature, its implementation or funding:

• Information about concept: Fabian Schmid, fs@studer-raimann.ch sr.solutions
  
• Information about funding: (name, e-mail)
• Information about implementation: (name, e-mail)

4 Discussion

Alex 11 Apr 2014: It would be easier to handle these suggestions if they would be split of in

• Guidelines that already exist (in my opinion they can be omitted completely in the document)
• Guidelines that conflict with existing ones
• Guidelines that are new

• I do not think that AND OR is better readable than && ||. && || are visually more distinguishable from surrounding variables "$var and $par" vs "$var && $par".
• Opening curly braces {, e.g. after class, if, else, ... are in separate lines in all code examples and in most of the ILIAS code. I would not like to change that. It visually separates the condition from the code, which I like. In know that in Javascript best practice is to put it in the same line, but I can live with this being different in PHP and Javascript.
• Class name prefix: I would object to change the guideline here, especially to remove the "il" prefix. Otherwise we would end up with inconsistent namings for years. I know that there are some places that do not respect this "il" prefix but the majority does. Use "ilDcl..." instead of "dcl...". Who should refactor all this stuff?
• Structuring of Classes: I am not sure if we should add any guideline here, but if, I would like to have setter/getter on top after the constructor. They come first and any specific functions later. This usually leads to the fact that newer (usually "specific") functions can be added simply to the end of the file, which supports readability and merging in my opinion. I also would like to group functions "by topic" and not simply put static ones together.
• ... to be continued.

5 Implementation

...