←

Contribute

You are welcome.

How can I contribute?

You can see the tasks that have to be done. But you can also do other helpful things.

Files

Source code

All text files have to be encoded in UTF-8 without BOM. Generally, UTF-8 is the default encoding on UNIX-like operating systems (like GNU/Linux and *BSD) and ISO 8859-15 is default one on Microsoft Windows.

The character newline must be LF (sometime called UNIX newline/endline). Unfortunately, Microsoft Windows generally used CR+LF.

If your editor manages EditorConfig, you have nothing to do, enjoy! Else if you are using Geany, go to "Edit" > "Preferences" > "Files" (tab), then choose "Unix (LF)" for line breaks and "UTF-8" as the default encoding. Else find yourself how configure your editor.

Coding style

The code must not be obfuscated or uglify, even for the purpose of reducing size or improving speed.

For indenting, you should use tabulations. It is lighter than multiple spaces and every one can choose what size tabulations have to be in his favorite text editor.

We use english, so please use it everywhere in the project (messages, variable/function/class names, documentation, commits, etc).

Names of variables, functions/methods, classes and everything else have to be clear, even if the name is a little longer. You also do not have to forget to write comments and documentation.

HyperText Markup Language

HTML must be W3C compliant. If it is possible, HTML has to be XML compliant, even if it is a bit longer.

HTML must not be used for the style.

Examples
Bad Good
<br> <br />
<option value="" selected> <option value="" selected="selected">
<option value="0">0<option value="1">1 <option value="0">0</option>
<option value="1">1</option>
<p style="font-weight:bold;">Text</p> <p class="bold">Text</p>
Cascading Style Sheets

CSS must be W3C compliant. You must not use prefixes.

Examples
/* 1 selector by line */
body > header,
body > footer
{
	text-align: center;
}
JavaScript

Classes should be written in upper camel case (example: AClassInUpperCamelCase). Variables, functions and methods should be written in lower camel case (example: aVariableInLowerCamelCase). Constants should be written in uppercase characters separated by underscores (example: A_CONSTANT).

The JavaScript engine should be considered as stupid
Bad Good
for(var i=0; i < 5; i++) for(var i=0; i < 5; ++i)
var i = 60 * 60 * 24; var i = 86400; // 60 * 60 * 24
if(i == 2) { return 'i == 2'; } else { return 'i != 2'; } return i == 2 ? 'i == 2' : 'i != 2';
return true; alert('useless'); return true;
var a = new HTML5Class(); if(a instanceof HTML5Class) alert('HTML5Class may be undefined'); var a = new HTML5Class(); if(typeof(HTML5Class) == 'function' && a instanceof HTML5Class) alert('No error');

Moreover, Closure Compiler can find potential warnings and errors. --warning_level VERBOSE is usefull for having more information. At least on GNU/Linux, if you do not want to have the output file in the stardard output, you can redirect it with --js_output_file /dev/null.

Documentation of JavaScript

The documentation syntax is JSDoc.

Compatibility

Compatibility is important. However, a clean code and easy readable code is better.
HTML, CSS and JavaScript engines that have at least 4 years are absolutely not important to support.

This program is free, with free as in freedom. Persons that want freedom need free programs, but not only someones, they need an entire environment. So up-to-date 100% free/libre environment must be supported.
Proprietary systems and engines can be supported, but they are less important.

The Zen of Python

Following the PEP 20 The Zen of Python is a good thing, even if the project does not use the Python programming language.

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
The Zen of RyDroid in Web

Medias

Only free formats that are supported and editable on free/libre engines that work on free/libre operating systems must be used. Moreover, the formats must not be encumbered with patents.

Images

Good examples of free/libre formats are SVG and PNG, a bad one is PSD.

Vector image formats (like SVG) should be preferred compared to bitmap image formats (like PNG or JPEG), because there are independant of the size of the screen and generally lighter. Lossless image formats (like PNG) should be preferred compared to lossy image formats (like JPEG), because quality is more important than size.

Audio

Good examples of free/libre codecs are Opus, Vorbis and FLAC. Bad examples are MP3, AAC, HE-AAC, AC3, WMA and Monkey's Audio (ape).

Third parties

Third parties elements (source code, medias, etc) can be used if there are under free/libre license compatible with the license used for this program. However, third parties elements must be inside the application and do not require elements that are outside.

Privacy

Nothing must be sent (even a HTTP(S) request) outside the app if the user has not explicitly accepted it.

This program must not encourage web sites, services, companies or anything else that do not protect privacy. For example, there must be no links that targets Google, Facebook, Apple, Microsoft or Amazon.

Tasks to do