Development:Coding: Difference between revisions
Helen Foster (talk | contribs) m (→Usability: rewording) |
|||
| (12 intermediate revisions by 5 users not shown) | |||
| Line 21: | Line 21: | ||
Consistent coding style is important in any development project, and particularly so when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality. | Consistent coding style is important in any development project, and particularly so when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality. | ||
Writing your code in this way | Writing your code in this way is an important step to having your code accepted by the Moodle community. | ||
Our [[Development:Coding_style|Moodle coding style]] document explains this standard. | Our [[Development:Coding_style|Moodle coding style]] document explains this standard. | ||
| Line 33: | Line 33: | ||
Any single script (in Moodle core or a third party module) can introduce a vulnerability to thousands of sites, so it's important that all developers strictly follow our [[Development:Security|Moodle security guidelines]]. | Any single script (in Moodle core or a third party module) can introduce a vulnerability to thousands of sites, so it's important that all developers strictly follow our [[Development:Security|Moodle security guidelines]]. | ||
==XHTML== | ==XHTML and CSS== | ||
It's important that Moodle produces strict, well-formed XHTML code, compliant with all common accessibility guidelines (such as W3C WAG). | It's important that Moodle produces strict, well-formed XHTML code, compliant with all common accessibility guidelines (such as W3C WAG). | ||
CSS should be used for layout. Moodle comes with several themes installed. The 'standard' theme, which should be a plain theme suitable to act as a building block for other themes. That should contain the minimal styling to make Moodle look OK and be function. Then Moodle comes with several other default themes that look good and demonstrate various techniques for building themes. | |||
This helps consistency across browsers in a nicely-degrading way (especially those using non-visual or mobile browsers), as well as improving life for theme designers. | This helps consistency across browsers in a nicely-degrading way (especially those using non-visual or mobile browsers), as well as improving life for theme designers. | ||
| Line 51: | Line 53: | ||
==Internationalisation== | ==Internationalisation== | ||
Moodle works in over | Moodle works in over 84 languages because we pay great attention to keeping the language strings and locale information separate from the code, in language packs. | ||
The default language for all code and documentation, however, is English (AU). | The default language for all code, comments and documentation, however, is English (AU). | ||
Full details: [[Development:Internationalisation|Moodle Internationalisation]] | Full details: [[Development:Internationalisation|Moodle Internationalisation]] | ||
| Line 65: | Line 67: | ||
==Usability== | ==Usability== | ||
See | See [[Development:Interface_guidelines| Interface Guidelines]] (under construction) | ||
==Performance== | |||
The load any Moodle site can cope with will, of course, depend on the server and network hardware that it is running on. | |||
The most important property is scalability, so a small increase in the number of users, courses, activities in a course, and so on, only causes a correspondingly small increase in server load. | |||
For more information and advice, see [[Development:Performance and scalability|Performance and scalability]]. | |||
==Database== | ==Database== | ||
| Line 96: | Line 106: | ||
[[Category: | [[Category:Coding guidelines|Coding]] | ||
[[es:Manual de Estilo de Código]] | [[es:Manual de Estilo de Código]] | ||
Latest revision as of 08:00, 14 May 2010
This page is the top-level page describing Moodle's coding guidelines. It's the place to start if you want to know how to write code for Moodle.
WARNING: Under construction RIGHT NOW!
Moodle architecture
Moodle tries to run on the widest possible range of platforms, for the widest possible number of people, while remaining easy to install, use, upgrade and integrate with other systems.
For more about this, see: Moodle architecture.
Plugins
Moodle has a general philosophy of modularity. There are over 25 different types of plugins, however many of these plugin types work the same way.
For more about the structure of plugins, see Moodle plugins.
Coding style
Consistent coding style is important in any development project, and particularly so when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.
Writing your code in this way is an important step to having your code accepted by the Moodle community.
Our Moodle coding style document explains this standard.
Security
Security is about protecting the interests and data of all our users. Moodle may not be banking software, but it is still protecting a lot of sensitive and important data such as private discussions and grades from outside eyes (or student hackers!) as well as protecting our users from spammers and other internet predators.
It's also a script running on people's servers, so Moodle needs to be a responsible Internet citizen and not introduce vulnerabilities that could allow crackers to gain unlawful access to the server it runs on.
Any single script (in Moodle core or a third party module) can introduce a vulnerability to thousands of sites, so it's important that all developers strictly follow our Moodle security guidelines.
XHTML and CSS
It's important that Moodle produces strict, well-formed XHTML code, compliant with all common accessibility guidelines (such as W3C WAG).
CSS should be used for layout. Moodle comes with several themes installed. The 'standard' theme, which should be a plain theme suitable to act as a building block for other themes. That should contain the minimal styling to make Moodle look OK and be function. Then Moodle comes with several other default themes that look good and demonstrate various techniques for building themes.
This helps consistency across browsers in a nicely-degrading way (especially those using non-visual or mobile browsers), as well as improving life for theme designers.
Full information is here: Moodle XHTML
JavaScript
In general, everything in Moodle should work with JavaScript turned off in your browser. If you do have JavaScript enabled it should only improve usability (not add features).
This is important for accessibility, and in line with the principles of unobtrusive JavaScript and progressive enhancement.
See the Moodle JavaScript guidelines for more information.
Internationalisation
Moodle works in over 84 languages because we pay great attention to keeping the language strings and locale information separate from the code, in language packs.
The default language for all code, comments and documentation, however, is English (AU).
Full details: Moodle Internationalisation
Accessibility
Moodle should work well for the widest possible range of people.
See: Moodle Accessibility
Usability
See Interface Guidelines (under construction)
Performance
The load any Moodle site can cope with will, of course, depend on the server and network hardware that it is running on.
The most important property is scalability, so a small increase in the number of users, courses, activities in a course, and so on, only causes a correspondingly small increase in server load.
For more information and advice, see Performance and scalability.
Database
Moodle has a powerful database abstraction layer that we wrote ourselves, called XMLDB. This lets the same Moodle code work on MySQL, PostgreSQL, Oracle and MSSQL.
We have tools and API for defining and modifying tables as well as methods for getting data in and out of the database.
Overview: Moodle Database guidelines
Events
Moodle allows inter-module communication via events. Modules can trigger specific events and other modules can choose to handle those events.
Full information: Moodle Events API
Unit tests
Unit testing is not simply a technique but a philosophy of software development.
The idea is to create automatable tests for each bit of functionality that you are developing (at the same time you are developing it). This not only helps everyone later test that the software works, but helps the development itself, because it forces you to work in a modular way with very clearly defined structures and goals.
Moodle uses a library called simpletest (not very extensively yet though!) that makes writing unit tests fairly simple. Our unit testing is currently not deep but we want to improve this.
Full information here: Moodle Unit Tests
