What is a Bad Programmer?

Posted by Pierre-Edouard Guerin · 3 min read · Published on December 23, 2023

Coding refers to the act of writing instructions in a programming language. In that sense, the coder is also a programmer. The program must serve a clear purpose: automating a routine task, performing repetitive or complex calculations, managing data, and so on. In bioinformatics, programs are designed to transform raw biological data into formats that can be used by other specialists for further analysis.

The program is not a static code but a living thing. The environment around it can evolve, requirements may change, and the program must adapt accordingly to remain useful. Therefore, the code has to be modified and tested by anyone as often as needed.

The code is ambivalent:

Sequence of instructions that is run by the computer.
Text that must be easy to read.

Best coding practices have been introduced to improve code readability (by other humans) and, consequently, ease program maintenance. In this context, bad or good code is, above all, code that either jeopardizes or saves the life of the program.

What is a bad code?

Does not do its job!
Difficult to change.

Reciprocally, a good code

Works!
Is easy to change.

Therefore, what does a good programmer?

Spends few time refactoring their code.
Writes new features.

Unreadable code

A good code is comprehensible by anyone.
A good code is structured into modules. Divide code into small, manageable parts.
One single context for each part.
Variables must have clear, self-explanatory names.
Syntax is consistent:
- kebab-case: Words are all lowercase and separated by dashes -.
- camelCase: The first word is lowercase, and each subsequent word starts with a uppercase.
- snake_case: Words are all lowercase and separated by underscore _.

What is a module?

A module is a subprogram. It is a file or a collection of files of written code. This code can be reused and invoked from other parts of the program. The term module is broad and can refer to a component, library, package, or assembly.

The code is too complicated!

When it has no modules (always divide the code in smaller parts)
When it is too nested
- ⚖️ Golden rule: no more than 3 indentations!

for
  for
    for

To ensure that changing one element of the code does not force you to change other parts of the code.

Last but not least

Reduce coupling between functions as much as possible.
All functions must be easy to test.
Don't repeat yourself.

References

The Pragmatic Programmer

Andrew Hunt and David Thomas

From journeyman to master, 1999. ISBN-13: 978-0135957059

Published on December 23, 2023

Relevant Tags

About the Author

Pierre-Edouard Guerin

Bioinformatician