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

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()
}

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 is the expected and the right value is the actual one. To quote ChatGPT:

In Rust, when using the assert_eq!() macro, there is no strict convention on which value should be on the left and which should be on the right. However, it is common practice to put the expected value on the left and the actual value on the right. This practice is mainly for readability purposes and to make it clear to other developers what the expected outcome is.