WIP: Clean code

putu agastya
Software Project Course Blog - Marjinal
3 min readApr 30, 2020

Menurut Robert C. Martin, penulis buku Clean Code: A Handbook of Agile Software Craftsmanship, Bahkan kode yang buruk dapat berfungsi. … Setiap tahun, banyak waktu dan sumber daya yang signifikan hilang karena kode yang ditulis dengan buruk

Clean Code Cheatsheet (sumber)

Dalam pengembangan sebuah aplikasi perangkat lunak, kita tidak hanya menulis kode untuk di mengerti komputer. Namun, code yang kita tulis juga harus dimengerti programer lain. Prinsip clean code membantu kita menulis kode yang dapat dimengerti mesin dan manusia lain.

Robert C. Martin menulis tentang clean code pada buku Clean Code: A Handbook of Agile Software Craftsmanship, rangkuman dari buku tersebut dapat dibaca pada tautan berikut : https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29

General rules

  1. Follow standard conventions.
  2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
  3. Boy scout rule. Leave the campground cleaner than you found it.
  4. Always find root cause. Always look for the root cause of a problem.

Design rules

  1. Use dependency injection.
  2. Follow Law of Demeter. A class should know only its direct dependencies.

Understandability tips

  1. Be consistent. If you do something a certain way, do all similar things in the same way.
  2. Use explanatory variables.
Contoh penamaan variable yang menjelaskan dirinya sendiri
  1. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
  2. Prefer dedicated value objects to primitive type.
  3. Avoid logical dependency. Don’t write methods which works correctly depending on something else in the same class.
  4. Avoid negative conditionals.

Names rules

  1. Choose descriptive and unambiguous names.
  2. Make meaningful distinction.
  3. Use pronounceable names.
  4. Use searchable names.
  5. Replace magic numbers with named constants.
  6. Avoid encodings. Don’t append prefixes or type information.

Functions rules

  1. Small.
  2. Do one thing.
  3. Use descriptive names.
  4. Prefer fewer arguments.
  5. Have no side effects.
  6. Don’t use flag arguments. Split method into several independent methods that can be called from the client without the flag.

Tests

  1. One assert per test.
  2. Readable.
  3. Fast.
  4. Independent.
  5. Repeatable.

Pada contoh diatas setiap test memiliki 1 assertion contoh, assert apakah admin pengguna anonim ditolak jika mencoba mengakses dashboard kontributor. Setiap test readable dengan flow yang jelas dan penamaan variable yang tepat.

Code smells

  1. Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
  2. Fragility. The software breaks in many places due to a single change.
  3. Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
  4. Needless Complexity.
  5. Needless Repetition.
  6. Opacity. The code is hard to understand.

--

--