Skip to content

Context to Keep in Mind when Coding

Coding in General

  • Can write new code or refactor - don't try to do both at the same time.
  • YAGNI! (Remember, You Ain't Gonna Need It)
  • Don't Repeat Yourself (applies everywhere... documentation, databases, etc)

The easiest code to maintain is the code you don't write

Exceptions

handle errors with exceptions rather than return codes.  This allows the error handling code to be factored out from general code

Methods

A function/method should do one thing only.  Each of the following counts as a single thing:-

  • handle errors
  • return some value
  • perform an action

Test Driven Development

Stages

  • write failing test
  • write code to pass test
  • repeat

Minimalism in Coding

Avoid Dependency Clutter

Think before you install a library/package/module

Every new dependency has the following effects:

  • increases the size of the project
  • the development team has to learn how to properly use the new dependency
  • regular updates may be required (for security issues for example) - means that the project has to be tested (and possibly refactored) with every update

There's usually no value in commented out code

It just causes noise. And let's be honest, if you need to go back to it, that's what source control is for.

Less is More - Don't write Code "just in case" - YAGNI

This is adding code noise in exchange for the possibility of it eventually becoming valuable

Challenge Your Ideas

Don't do stuff just because "we have always done it this way". Challenging ideas will help you get a better understanding of them and probably find better solutions or even issues with previous approaches.

Of course, there’re times to question things and there’re times to let things go to be able to move forward fast. Don’t get caught in analysis paralysis trying to question every little thing.

Take Advantage of What You Already Have - Code Reuseability

Reuse code wherever you can - it saves time, makes the code cleaner and easier to maintain, etc. Be aware of the costs of writing new code: possible bugs, more time spent building, documenting and testing the feature, you may have to introduce the team to the new solution, etc.

Avoid "shiny object" syndrome

There are features that are more fun to build, but we need to focus on what's important: what do our users need the most?

Object Orientated Coding

SOLID Principles

  • Single responsibility principle - a class should only have ONE reason to change
  • Open for extension / closed to modification
  • Liskov Substitution Principle - derived or child classes must be substitutable for their base or parent classess
  • Interface Segregation - many smaller interfaces are better than one large interface
  • Dependency Inversion - depend on abstractions (e.g. interfaces) not concretions

Code Smell - Things to avoid

  • Long Methods
  • Identifiers are too long or too small
  • Pointless comments

OOP Code Smell

  • God Objects - classes that do EVERYTHING
  • Feature Envy - class that only uses methods of another class

C++

Use smart pointers whenever you can