The unofficial coding best practise and code formatting conventions for XBMC

fyi, mplayer (which xbmc a/v player is based on) has a strict policy against code beautification!, and i have to agree with that when it comes to our mplayer-core in xbmc and for all other code that's been ported from other sources (eg. not written from scartch). if for exampel our mplayer-core code was 'beautified' then it would be harder to update it from the latest mplayer cvs as the code would not be layed-out the same, same goes all other libs and code we use in xbmc that we update quite often (like libcdio, filezilla, ffmpeg, xvid, etc...). only code that can be beautified without consequenses are the xbmc code that has been written from scratch by our own developers, (like the xbmc-gui).

hi, i just have a quick question, maybe slightly off-topic but i didn't know where else to ask. i read on the c++ faq lite (http://www.parashift.com/c++-faq-lite/fr...l#faq-16.7) that the value returned by the "new" operator should not be checked for zero as it throws on exceptions. this seems to be the way new is called most of the time in xbmc code but then i stumbled upon this msdn bit (http://msdn.microsoft.com/library/defaul...ess_25.asp) which states the opposite.

Quote:if unsuccessful, by default new returns zero.

so which is true, should i check my news or not?

tought i :bump: this, 'even' mediaportal now have guide-lines, maybe we can use that as a base (though obviously remove the c# stuff)
....what do you all think? is anyone (developer) willing to put together a draft of a basic guideline for adding new code and changing old one?

i like to bump this discussion once again with a link to a essay titled "comments are more important than code" (which been 'slashdotted')

• XML Filenames - I see you've changed all the files to be lowercase and added underscores in the custom files (views_common.xml etc). A large number of these names are fixed in the XBMC code so can't conform to the underscore naming (DialogYesNo.xml for example) so I'd suggest we don't use the underscores and stick with camel (mixed) case to make them easier to read?
• Image Filenames - Again there are some images names that are hard-coded into XBMC (such as DefaultFolderBig.png) but the majority of the images we use can be named as and how we like. I would stick with the lower case names with underscores that you have in your zip.
• Attribute/Element Names - we need to be consistent with naming of things within the xml (such as fonts, includes, viewtype labels etc) and I would propose we use camel case again (without underscores).
• Info labels/Built In Functions - underscores can't be added in these and having them all lower case makes them more difficult to read so I would go for camel case again.
• Descriptions - These can be free form (and without underscores replacing spaces).
• Tabs/Indents - tab width of 2 and convert all tabs to spaces.
• White Space - Blank lines between distinct code blocks and comments to distinguish code areas (such as a comment block to group together includes relating to video screens etc)-
  

Also, maybe a brief statements on line endings would be useful?

Sorry to drege up an old topic, but this thread is still useful for those of us just starting out in the code. I've run into a variety of switch statement formats. One of which seems better than the current documented standard (although with the Quote thingy in the wiki the spaces might have just gone away).

Thanks - yeah, the formatting just went haywire.

Cheers,
Jonathan

Hi there,

as no one here really responded to the doxygen proposals of Gamester17 and I saw in the wiki a guideline saying one _should_ use doxygen to comment the code: what doc-style for doxygen should one use? Doxygen allows for multiple comment types (see http://www.stack.nl/~dimitri/doxygen/docblocks.html) and I didn't really found any reference of doxygen doc in the code as of yet.

jmarshall has started doing some doxy, see e.g. utils/JobManager.h

Hey everyone

I'm currently working on making XBMCs JSON RPC api compliant with the JSON RPC 2.0 specification (see Trac Ticket #10095 in combination with Track Ticket #10763). During development I came across the following two questions:

1. How should the code (mainly methods and members) be documented? I saw some files using doxygen style with \brief, \param and \return. Is this the prefered way to do it? And do you use some kind of groups with \ingroup or something like that?

2. I'm working on using a Service Mapping Description (SMD) to describe all the methods in XBMCs JSON RPC api but that requires quite some text. Until now I copied the text into the code (simply to be able to test if it works at all) but the SMD gets bigger and bigger and has reached a size of a few ten kBs (uncompressed).
So I have to get away from the "copy into the code" hack and need a way to read the SMD from a file. How are additional files handled by XBMC? It's not like some configuration file which can be changed by the user manually. If someone would change something in the SMD it would probably cause json rpc methods to fail. Where would such a file be stored and under which path could I access it in the code? Or is there a different approach for such files?

Thanks for your help.