Elgg Core and Plugin Coding Standards

This page is reserved for comments.  Please see the most recent copy of the coding standards at http://code.elgg.org/elgg/trunk/CODING.txt

  • Just opinion:

    1 - Mistake, a place of nightmare hell

    2 - Hard error, user-dependent settings. In order to save presentation always identical, all tabs must be "4 spaces"

    5. Shitty code (and viotates rule 2)

  • Of course you may use whatever standards you want in your own project, but for Elgg core, its plugins and all patches submitted to trac will be in this this format. Users developing for Elgg core will be expected to configure their tools to match these settings. This is standard and accepted practice among shared projects with distributed developers, and these standards are similar to standards in other projects.

    Also, please remember this is a shared community and many users don't appreciate strong language like in your 5th point.

  • When I work in my projects, we have rules before 1-st line of code, thus - your remark isn't correct and even reasonable.

    I don't want to establish my rules in foreign projects, but - If I see a source of future big problems in publish drafts somewhere - I notify author about this. Any rules do not have independent value, they must help with the simpler and more reliable solution of problems, but not amuse ego of the author/project leader... Suggestedstardard of codings HAVE some flaws, and even after fix these problems there rules wll not make such code (as example - from http://github.com/Elgg/Elgg/blob/master/engine/lib/version.php) better, code, not formatting, which is just nice now

    	/**	 * Get the current version information	 *	 * @param true|false $humanreadable Whether to return a human readable version (default: false)	 * @return string|false Depending on success	 */		function get_version($humanreadable = false) { 			global $CONFIG;			if (include($CONFIG->path . "version.php")) {				if (!$humanreadable) return $version;				return $release;			} 			return false; 		}
    Anybody in Curverider can at least sometimes listen and understand?!
  • Hi Brett,

    I notice that point 7 seems to be different to how the core Elgg libraries are currently written (at least the ones I've just had a look at).  They seem to use underscore_character() for function names, and UpperCamelCase for classes, but lowerCamelCase() for method names.

    Which should we code to?

  • @Richard you're absolutely right.  Methods should use lowerCamelCase().  Also, the most recent coding standards will always be in the SVN at http://code.elgg.org/elgg/trunk/CODING.txt

  • Also noticed the Elgg core uses true/false rather than TRUE/FALSE, and null seems to be used more frequently than NULL.

    Hope I'm not being too pedantic - I'm trying to get our own coding standards into shape, and starting from the Elgg ones as a base will cause less heartache when it comes to releasing code!

  • It is perhaps pretty late to make a new suggestion, but have you considered going with an established standard like PEAR or Zend, rather than writing your own from scratch?  PHP_CodeSniffer can detect conformity to these standards out-of-box, which seems to me a very useful tool to be able to take advantage of.


  • @Evan - Reasonable question. I don't think there is that much of a difference between the Zend standard and this one. Last time I checked it looked like this was a subset of Zend. The tabs instead of spaces goes back to the original core developers (which obviously conflicts with PEAR and maybe Zend?).

    I think when Brett created these he was fighting back against some very specific problems left behind by previous developers.