[Project_owners] Programming guidelines for extensions and add-ons

Matthew Wilson matthew at mjwilson.demon.co.uk
Sat Sep 10 15:20:00 EDT 2005

Karsten Düsterloh wrote:
> Michael Vincent aber hob zu reden an und schrieb:
>>>It might be a good idea to put up a coding guidelines document, but I 
>>>don't believe we can enforce any such thing.
>>I agree, but extension authors might want this *if* it also protects 
>>them from running into compatibility issues with other extensions, that 
>>should be part of it IMHO.

I think the following are excellent suggestions and are the kind of 
things which would be great to document with good examples:

> I'd say that the most important rule should be:
> *Don't pollute the global namespace!*
> That means:
> - When creating overlays, especially for much-overlayed files like
> mailwindowOverlay.xul or navigator.xul, do not introduce new global
> variables and functions. There are _plenty_ already, and they are likely
> to collide.
> If global stuff is needed at all, better use a _single_ global object
> variable, possibly named like your extension (if it is sufficiently
> distinct) and make all other stuff be a member/property of it.
> Eg: var global1;              var global = {g1 : 23,
>     var global2;           ->               g2 : 'huhu',
>     function global3()                      g3 : function(){...} };
>     {...}
> - When using the preference system to store values for your extension,
> put your prefs under extensions.$extensionname$.*.

On the other hand I think it's less valuable trying to emphasise the 

> Most programmers tend to develop a very personal coding style and naming
> scheme that unenforcable guidelines can't change anyway, but I think
> it'd be good if extension authors try to follow the Mozilla guidelines
> and the style used in the Mozilla files themselves (eg two space indent
> with no tabs).
> And it's possibly a good idea to have identifier names and comments in
> English... ;-)


More information about the Project_owners mailing list