Instead of rapidcode..

• have a backlog
• design what you need to do next in your code
• design in English, write in code

For this code session, think:

• what is your DoD (know when you are done)

Then:

• code it
• lint it
• solve the manual cases, that linter could not do
• test your code
• if tests pass, commit

Beautifying code

When you’re doing changes that supposedly don’t change the actual logic of your code, still it makes sense to be a bit careful. This is true especially if you know the setup of your coding environment is smoking hot and prone to change.

For example, when React’s JSX was new, some editors and editor plugins did not correctly parse JSX. This leads to either cosmetic trouble (like wrong code highlighting in your editor), but it might lead to outright wrong corrections done by a linter’s “fix” functionality.

Sometimes we simply don’t get yet the luxury of working with stable versions of tools.

In these cases there’s a simple thing you can do:

• run unit tests on your codebase
• if tests pass.. (as they should)
• run linter with automated fix of known problems
• run unit tests again
• tests should pass again – if not, your linter does something wrong