Our rules

Getting Started

Setup your Mac for Development

RULE: The Good Developer uses a Git GUI, unless he really really knows what he is doing. If you think you know what you are doing, statistics say you are probably wrong.

RULE: The Good Developer applies the company's policy to use VS Code.

Habits of Good Developers

RULE: The Good Developer writes down his "first creation" in the form of comments when writing code.

RULE: The Good Developer checks preconditions, and aborts early when those aren't met.

RULE: The Good Developer defines terms and shares terminology.

RULE The Good Developer takes responsibility. He corrects the slightest mistake and corrects every mistake.

RULE: The Good Developer knows that avoiding shortcuts is better than having to document them with @TODO. He also knows that not documenting shortcuts is beyond bad.

RULE: When a console warning or error, a linter warning or error or a typing error appears, you are taking a shortcut. When you write a block of code without the appropriate documentation, you are taking a shortcut. The Good Developer does not tolerate this and fixes the issue, even if it is not critical or not visible to the user.

RULE: The Good Developer puts documentation as close to the source as possible.

RULE: The Good Developer avoids separate (Swagger)files for API Documentation. He uses tools for inline documentation instead.

RULE: The Good Developer writes only correct markdown files and previews the result for verification.

Gituiqette and Peer Review

RULE: The Good Developer always commits and pushes all his work at the end of the day, adding "WIP" to his commit message if necessary..

RULE: The Good Developer always keeps his Git repository in the state he would want to find it in on his first day as a developer.

RULE: The Good Developer doesn't fast-forward when merging, unless there is a good reason.

RULE: The Good Developer systematically removes all old code and its dependencies.

RULE: Use our Commit Messages convention for all Git Commit Messages:
Capitalize the commit message, do not add a full stop, use imperative form.
Keep the commit message short and simple (< 50 characters)
Add a body by leaving a blank line after the subject.
No process/resolve feedback commits
Indicate "Work In Progress" commits by prefixing with "WIP"

RULE: The Good Developer never commits secrets, passwords or keys unencrypted to Git.

The Visual Aspects of UIs

CSS Flexbox Layout Deep Dive

RULE: As soon as the Good Developer adds display: flex to an element, he adds a flex property to every new flex item (this is, every direct child of that element).

RULE: When the Good Developer uses the flex property, he always specifies the flex-grow, flex-shrink and flex-basis parameters explicitly.

RULE: The Good Developer knows that flex items can never be inline elements.

RULE: The Good Developer does not use space-between to create columns with gaps between them. He uses column-gap instead.