These guidelines are both convention based and opinionated. They are designed for use in my personal projects and represent a combination of industry best-practice and my own preferences.
"Every line of code should appear to be written by a single person, no matter the number of contributors."
— The Golden Rule
There is really no universal "correct" when it comes to how you write code or how you build projects — it's about creating a system that:
- Helps you focus on producing great work.
- Produces work that can be maintained long-term.
- Can scale up for larger teams and projects if needed.
- Makes it easy to on-board new staff and contributors.
A "coding styleguide" is typically more suited to product teams, but I believe all developers should strive for a degree of standardisation and order in their code.
When followed, guidelines will:
- Set the standard for code quality across a project.
- Promote consistency and accuracy.
- Give contributors a feeling of familiarity across codebases.
- Increase productivity (hopefully!)
I fully recognise that there are many approaches different to mine which are as good or better. I've used many and am totally pragmatic.
Pick the right tool for the job: it's about the solution, not the implementation.
To reference Silicon Valley, when it comes to Tabs vs. Spaces, I'm sort of a "Tabs or Spaces" guy. They're both fine.
These guidelines are designed to enable consistent and clear work on projects — for each technology they define:
- Approach, guidance and rules.
- Templates, scaffolding and frameworks.
- Style guides and copywriting.
- Supporting resources.
Note: Guidelines will link to any personal or third-party boilerplate repos for use or reference.
Secondary guidelines:
...TBD.
MIT © 2017 Aaron Bates (http://aaronbates.me)
- JavaScript guidelines
- Sass guidelines
- Secondary guidelines
- Additional guidelines? Rails? Python?