Best Practices

General information

• The Mistakes I Made As a Beginner Programmer by Samer Buna
• 7 daily practices of top developers by Bennett Garner

Clean code

• Clean code for javascript (but applicable for any language)

Git Messages

• Commit messages guideline
• conventional messages

Preference: Order source files from abstract to concrete

In the last years the best practice developed at Serlo that we order code in source files from abstract to concrete, from general concepts to more specialized concepts (the general concepts depend on). Here concepts mean software structures like functions, classes, structures, etc. So always start with the most general concept and then go to its dependent concepts. Thus we find the source code more readable and understandable. Example:

/* ✅ Good */
function main() {
  do_stuff()
}

function do_stuff() {
  do_more_concrete_stuff()
}

function do_more_concrete_stuff() {
  partey()
}

What we do not want to do:

/* ❌ Bad */
function do_more_concrete_stuff() {
  partey()
}

function do_stuff() {
  do_more_concrete_stuff()
}

function main() {
  do_stuff()
}

Reason:

• The most abstract / general constructs tend to also be the most important ones. In the above example main() would describe what the script does and thus tells a high level story for new developers about why this is needed.
• The most concrete / general constructs are also the one which are exported by a module and thus needed to be read more often.
• The more concrete / specialized constructs can only be understand when you have the overall / high level overview of the code (which is given by the more general constructs)

TypeScript / JavaScript

Testing

• Javascript testing best practices

Rust

Take care that in assert_eq() the left value is the expected one

In order for us to better understand the code we follow the convention that the left value in assert_eq and assert_neq is the actual and the right value is the expected one.