In a previous post we have discussed why "clean code" is so intangible and subjective phenomenon.
We also mentioned that many common "code smells" are usually heuristics and not hard tests.
Are there any objective ways to differentiate good and bad code? Luckily, some of the original "code smells" are quite objective and hard to argue with. For example:
👉 Mysterious Name: functions, modules, variables or classes that are named in a way that does not communicate what they do or how to use them.
👉 Cyclomatic complexity: too many branches or loops; this may indicate a function needs to be broken up into smaller functions, or that it has potential for simplification/refactoring.
👉Data clump: Occurs when a group of variables are passed around together in various parts of the program. In general, this suggests that it would be more appropriate to formally group the different variables together into a single object, and pass around only the new object instead.
👉 Too many parameters: a long list of parameters is hard to read, and makes calling and testing the function complicated. It may indicate that the purpose of the function is ill-conceived and that the code should be refactored so responsibility is assigned in a more clean-cut way.
👉 Long method: a method, function, or procedure that has grown too large.
In the following posts I will explore every one of them, so don't forget to click "follow" button to not miss out!
Top comments (4)
Well said.
I have one absolute rule:
Everytime this rule is not observed we fall into this well known trap:
haha, yeah, that's funny! Regarding the unit tests since I am passioned TDD practitioner I don't usually have problems with this sort of things - no code should ever be written w/o a failing test
Nice ! waiting for that list
Code Smells are everywhere!
Thank you - I am really happy you liked that. We will start with Long methods first