Skip to content

Latest commit

 

History

History
77 lines (59 loc) · 2.49 KB

CONTRIBUTING.md

File metadata and controls

77 lines (59 loc) · 2.49 KB
Raw

Thank you for contributing SwissRETS

Submitting a change request or an idea

  1. Go to the new issue page
  2. Make sure you fill only a single topic per issue
  3. Choose your template
  4. Please use english
  5. Submit

Pull request process

  1. Ensure all your changes follow the principles and rules of this document.
  2. Update the documentation (Wiki) with details of changes, if needed.
  3. Increase the version number according to semver using npm version patch|minor|major
  4. A maintainer will then take care about merging the pull request.

Developing - before you start

You're very welcome to fork the project and send pull requests.

  1. Use an editor that supports Editorconfig or install the plugin
  2. Install Node >8
  3. Install .NET core SDK
  4. Fork the project - hit the Fork button on qualipool/swissrets - top right corner
  5. Clone your fork locally
  6. npm i
  7. npm start this brings up nodemon to re-run all tests if the schema or example files change.

Coding priciples

Mainly targeting the ./schema/schema.xsd

While we strive for all three, if we have conflicts, this list acts as priorities.

  1. Consistency
  2. Cleanness
  3. Ease of use

Consistency

SwissRETS is predictable.

  • Always solve the same things the same way
  • Have clear naming rules (TODO: add link)
  • Take time to refactor inconsistencies

Cleanness

SwissRETS is tidy and clean

  • Use real english words to name things
  • No abbrevations
  • Proper indentation (4 spaces)
  • Use syntax checks

Ease of use

SwissRETS is easy to use

  • We try to have as little documentation as necessary
  • Try to write selfspeaking code, to avoid documentation

Naming things

-> schema/schema.xsd

General naming rules

  • use real english words
  • for node and attribute names use camelCase
  • for attribute values use 'dash-separated-lower-case-words'
  • use a top-down naming schema, start with the broadest thing first and become more specific after
    • good: entryHallHeight, baths
    • bad: heightOfEntryHall, numberOfBaths

XML best practice

tags should have values

  • avoid using empty tags, whenever possible

tags over attributes

  • when in doubt, use tags over attributes
  • tags are easier to document and extend in the future
  • tags requre less documentation