Overview

• Generic
  • General
  • Comments
  • Documentation
  • Exceptions handling
  • Experimental Features Without Feature Branches
  • Project specific
• Testing
  • Types of tests
  • Developing using tests
  • Structure of a test
  • Smells
  • Naming conventions
  • Test fixtures, setUp and tearDown
  • Tests description - docstrings
  • Rerefences
• Review
  • General
  • For person requesting a review
  • For person reviewing changes
  • Overview of the GitHub and Trac integration
• Bugs and Tech-Debt
  • General
  • Defects and Release Blockers
  • Technical Debt
  • References
• Leave / Holiday
  • General
  • Vacation
  • Other legal leaves
  • Unused leaves
• Library
• Release process
  • General
  • Release Review Process
  • Release Notes
• Work
  • General
  • You are in control
  • Stay focus on what you do
  • Asynchronous tasks
  • Staying Healthy
  • Communication
  • Well documented, small tasks based work
  • Tools
  • References
• Python
  • General
  • Mixin
  • Project specific
• JavaScript
  • General
  • Prevent polluting the global scope
  • Defining classes
  • CSS interaction
  • Test styleguide
• CSS, LESS and Styles
  • CSS Syntax Elements
  • General
  • CSS Class naming
  • Rules definition
  • Layout and Typography separation
• HTML, XML and other markups
  • General
  • CSS interaction
  • HTML tags usage
• Bash
  • General
  • Path constants
  • Function Definition
  • Case Syntax
  • IF/THEN/ELSE
  • FOR
  • WHILE/UNTIL
  • References
• References
  • General
  • Python
  • JavaScript
  • CSS

These pages describe the guides used in Chevah project. They include programming style guides but also notes about the working on the project as a whole.

The content might be pedantic, but we hope that by following these guide you will find easier to collaborate and improve the quality of code and work.

Here are the overall rules of the project:

• Simple things should be simple, complex things should be possible. (Alan Key)

Based on previous rule the project should fit simple needs but also be able to scale for more complex usage.

Please note that these guides are continuously updated according to latest best practices.

We consider that arguments over these guides are not pointless. In the same time, it is hard to agree upon a style guide for all projects, and we don’t expect that everyone will agree with the lines from this page. If you have any comment or suggestions, please get in touch with us. You can do that over email, or adding an issue or pull request on chevah/styleguide - Github.

We try to automatically check software development rules using pocket-lint.

This is a collection of programming craftsmanship recommendations and ideas. Please let us know if we fail to properly cite the source.