Elgg Coding Standard: A need for uniformity.
One thing that really irks me about the plugins with Elgg is the lack of a uniform coding standard.
I think we should develop a standard on how to write a plugin for Elgg, I am willing to spearhead this as I've got some really interesting "helper" classes and various idioms that I think should be employed by developers to save time, keep the code relatively working the same way, and help us keep the sense of 'community' closer.
As this is an open source project, it is very important to make sure there's a coding standard involved so people can not be aggitated when browsing code written by others. A common preference is to keep lines under 80 characters as I'm constantly looking at more than one or two files (sometimes three files). Having lines that extend past 120 width is incredibly annoying and hard to read.
I also think that plugins need to be more object oriented; I know some of you might think, "There's no need for this," and I agree to a point, but for some plugins, I disagree. In an social website I'm building, I am heavily customizing Elgg. While there are fantastic plugins in Elgg, some of them are basically code copy/paste. Most of the functionality needs to expose an interface so anyone can extend, or utilize the code that everyone's used for their purposes. A great example of a few classes that are superiorly designed and easy to extend are the ElggDiskFilestore and ElggFile classes.
I will be releasing some plugins soon that have this "common" necessary functions exposed. I will contact their authors soon so they may review the code updates that I made.
Please share your thoughts as I'm very interested in hearing your opinions regarding this topic.
Mahmoud Abdelkader
- Brett@brett.profitt
Brett - 0 likes
You must log in to post replies.We'll be putting up an "official" coding standards document at some point. Following this document will be mandatory for having plugins / bits of code considered for Elgg Core. Since we can't mandate what everyone else does with their own plugins, it will be nothing more than recommendations for them.
I think things like line length, line endings, semantics, and documentation are good places to start. Later on, we'll get into when to use a class, when to use a new file...more objective things like that.
I'd suggest starting a page on the documentation wiki (http://docs.elgg.org) for plugin standards, but please mark it as a draft. Once we establish official core coding standards, it will be in a file in the core and the wiki for plugin standards can be updated if needed.
Of course, the ultimate decisions rest with the core dev team, but this will be a great start.