CONTRIBUTING.md

   1 * http://www.ruby-lang.org/ - The homepage of Ruby which has more links and some great tutorials.
   2 * http://rubyonrails.org/ - The homepage of Rails, also has links and tutorials
   3
   4 ## Coding style
   5
   6 When writing code it is generally a good idea to try and match your
   7 formatting to that of any existing code in the same file, or to other
   8 similar files if you are writing new code. Consistency of layout is
   9 far more important that the layout itself as it makes reading code
  10 much easier.
  11
  12 One golden rule of formatting -- please don't use tabs in your code
  13 as they will cause the file to be formatted differently for different
  14 people depending on how they have their editor configured.
  15
  16 ## Testing
  17
  18 Having a good suite of tests is very important to the stability and
  19 maintainability of any code base. The tests in the Rails port code are
  20 by no means complete, but they are extensive, and must continue to be
  21 so with any new functionality which is written. Tests are also useful
  22 in giving others confidence in the code you've written, and can
  23 greatly speed up the process of merging in new code.
  24
  25 When hacking, you should:
  26
  27 * Write new tests to cover the new functionality you've added.
  28 * Where appropriate, modify existing tests to reflect new or changed
  29 functionality.
  30 * Never comment out or remove a test just because it doesn't pass.
  31
  32 You can run the existing test suite with:
  33
  34 ```
  35 bundle exec rake test
  36 ```
  37
  38 You can generate test coverage stats with:
  39
  40 ```
  41 sudo gem install rcov
  42 rcov -x gems test/*/*.rb
  43 ```
  44
  45 The tests are automatically run on commit with the results shown at [http://cruise.openstreetmap.org/](http://cruise.openstreetmap.org/)
  46
  47 ## Comments
  48
  49 Sometimes it's not apparent from the code itself what it does, or,
  50 more importantly, **why** it does that. Good comments help your fellow
  51 developers to read the code and satisfy themselves that it's doing the
  52 right thing.
  53
  54 When hacking, you should:
  55
  56 * Comment your code - don't go overboard, but explain the bits which
  57 might be difficult to understand what the code does, why it does it
  58 and why it should be the way it is.
  59 * Check existing comments to ensure that they are not misleading.
  60
  61 ## Code Documentation
  62
  63 To generate the HTML documentation of the API/rails code, run the command
  64
  65 ```
  66 rake doc:app
  67 ```
  68
  69 ## Committing
  70
  71 When you submit patches, the project maintainer has to read them and
  72 understand them. This is difficult enough at the best of times, and
  73 misunderstanding patches can lead to them being more difficult to
  74 merge. To help with this, when submitting you should:
  75
  76 * Split up large patches into smaller units of functionality.
  77 * Keep your commit messages relevant to the changes in each individual
  78 unit.
  79
  80 When writing commit messages please try and stick to the same style as
  81 other commits, namely:
  82
  83 * A one line summary, starting with a capital and with no full stop.
  84 * A blank line.
  85 * Full description, as proper sentences with capitals and full stops.
  86
  87 For simple commits the one line summary is often enough and the body
  88 of the commit message can be left out.
  89
  90 ## Sending the patches
  91
  92 If you have forked on GitHub then the best way to submit your patches is to
  93 push your changes back to GitHub and then send a "pull request" on GitHub.
  94
  95 Otherwise you should either push your changes to a publicly visible git repository
  96 and send the details to the [rails-dev](http://lists.openstreetmap.org/listinfo/rails-dev)
  97 list or generate patches with `git format-patch` and send them to the
  98 [rails-dev](http://lists.openstreetmap.org/listinfo/rails-dev) list.
  99