Bad code traits

Mohammed Ragab
2 min readJan 7, 2020

--

There are some guidelines about how to write a clean code but some engineers think about clean code that includes some complicated design patterns such as CQRS, mediator, and Observer or patterns like that but writing clean code very simple, try to think about simplicity, and do not use complicated patterns if your project doesn’t need that,over-engineering may lead you to bad code also.

Your code looks bad if you do the following

  • If your code repeats itself
  • If you are not able to add unit tests to code, the best definition of bad code for me is Michael Feathers one “Code without tests”
  • If there is no way to test the code except an end to end test
  • If you are program to implementation not to interface or the high level of architecture depends on details of low-level of architecture
  • If you are consuming more flow of control like “if condition” instead of object-oriented principle “overloading”, but take care that is not mean replacing every if condition with a pattern
  • If you are consuming deep inheritance instead of composition over inheritance
  • If you are break encapsulation by making members and fields public
  • If you are including mutable objects because it will lead to more side effects in the runtime environment
  • If your code includes two or more classes depend on one class “Tightly coupled problem”
  • If your code includes functions each of them responsible for many operations
  • If your code consumes machine resources
  • When you need to change some logic of the existing function and going to edit this function instead of extending a new one, “open-close principle” make your code easy to re-test

Finally, I want to say you do not need to include more design patterns or complicated patterns to make your code cleaner, you shouldn’t use a design patterns if you are not sure you have the 100 % of the problem that pattern resolve it, just think about simplicity, the good software engineer is one who solves the complex problems by the simplest solution as much as possible

References:

  • Clean code (Uncle pop book)
  • Working effectively with legacy code (Michael Feathers book)

--

--

No responses yet