Difference between revisions of "Coding practices"

From Yabause
Jump to: navigation, search
(+ {{Yabause Manual}})
Line 1: Line 1:
 +
{{Yabause Manual}}
 +
 
== Introduction ==
 
== Introduction ==
 
While not a strict code of conduct, individuals who constantly don't follow these guidelines may find themselves without cvs access or have their commits reverted. Remember, it's all about keeping things fun and productive for -everyone-.
 
While not a strict code of conduct, individuals who constantly don't follow these guidelines may find themselves without cvs access or have their commits reverted. Remember, it's all about keeping things fun and productive for -everyone-.

Revision as of 18:07, 1 June 2008

Yabause Manual
For users
For developers
edit

Introduction

While not a strict code of conduct, individuals who constantly don't follow these guidelines may find themselves without cvs access or have their commits reverted. Remember, it's all about keeping things fun and productive for -everyone-.

Coding

  • #define's are -not- functions. Please don't use them as such. It makes things impossible to debug if problems arise.
  • Make sure to support big-endian and little-endian cpu's.
  • Avoid game-specific hacks. Either fix it right the first time or don't fix it at all.
  • Speak english. Code and comment your code in english.
  • When emulating new devices or processors, try to make use of some kind of warning or error message whenever an unsupported feature is used(it just makes it easier for debugging).
  • All source files should have a copyright notice at the top of the file stating who wrote the code, the year it was written it, and any specific license it's under.
  • All variables should be declared at the beginning of the function, if, for, while, etc. to maintain compatibility with Visual C++.

Commiting

  • Check your code before commiting. It should be compilable and working.
  • Make sure you diff the code against the current cvs to make sure that anything you don't want included isn't included. There's really no excuse for accidently commiting something you didn't want included.
  • Try to not to break other ports when doing port dependent changes. If it happens, at least keep the port maintainer aware of any potential problems.
  • Keep code as clean as possible. If there's code that's just used for debugging, it should either use one of the debug output functions or it shouldn't exist in code.
  • Code should be either simple to read, well documented, or a combination of both.
  • Commit early and often. It keeps down duplicate work and makes things easier to integrate without breaking things.
  • Anything added to cvs should be in source form. No external libraries, headers, binaries or anything of the sort should be in cvs. Settings files such as .ini files should also not be included.
  • Everything must be GPL compatible. And just because some code is open source, it doesn't mean it's necessarily GPL compatible. Such licenses that are not compatible include but are not limited to: Mame Distribution License, the original BSD license. For a full list of compatible and non-compatible licenses, please refer to GNU's list.