KISS

Keep It Simple, Stupid

Don't repeat yourself

No data structure nor algorithm should appear twice. Duplicity incrases the challenge of changing, mantaining and reading the code.

There are plenty of strategies for reusing code. Use them.

You aren't going to need it (YAGNI)

Never add any kind of functionality that you don't directly need.

You sacrifice your own time and you're unlikely testing and documenting it.

Single responsibility principle

Each module/class/function/method should have a clear encapsulated responsibility over the whole software, so it has a single reason to change.

Fail fast

Find your errors as early as possible

Fail fast

• Better at coding than at compiling
• Better at compiling than at executing
• Better at executing than at debugging

Fail fast

Better at coding than at compiling

• Use a powerful IDE
• Save your files regularly

Fail fast

Better at compiling than at executing

• Activate warning flags:
  -Wall -Wpedantic -Werror
• Use "safety" keywords:
  public private const override
• Use static asserts (or C++20 concepts):
  static_assert<...,"...">

Fail fast

Better at executing than at debugging

• Checks on execution:
  #ifndef NDEBUG ... #endif
• Asserts (or C++26 contracts):
  assert(...) pre(...) post(...)
• Test driven development

Test driven development (TDD)

Create your test code and production code simultaneously

TDD cycle

• Create a test that shows error or missing feature

TDD cycle

• Create a test that shows error or missing feature
• Correct that error in your code

TDD cycle

• Create a test that shows error or missing feature
• Correct that error in your code
• Refactor to acomodate the new code and start again

TDD advantages

• Thinking about the test before thinking about the solution
• Keep compatibility with previous test
• The testing code forces your production code to be reusable

TDD example

TDD example

TDD example

TDD example

TDD example

TDD example

TDD example

TDD example

TDD example

TDD example

TDD example

TDD example

TDD example

Test driven development

There are tools for facilitating TDD

• Google test
• Catch2
• CTest (integrated with CMake)

Advice from other courses

We asked other MRGCV professors what is their advice for you, seeing code from previous years' students

Advice from other courses

Sometimes it is easier to use debugging tools than to run full executions while experimenting with parameters, particularly if execution can take several minutes.

Advice from other courses

Use functions: it is suprisingly common to see "copy and paste" code that could be easily abstracted as a function.

Advice from other courses

Avoid side effects when possible. These are represented by global variables, non-const reference parameters...

Advice from other courses

Don't create useless code, where useless means both that you are not going to use it or that it is not needed to obtain the solution

Advice from other courses

Do not "hardcode" program parameters that you need to change to experiment with: obtain their values from a commandline or from a file (.ini, .xml ...)

Advice from other courses

Produce readable code, comment it when needed. Even better than commenting the code, use function and variable names that are so clear that they can be understood even without comments.