Clean code explained, nicely. I 'll leave only this as food for thought:
Regarding the fewer params in a method, sometimes it might not be the best practice.
Assume you are a consumer app and you have 2 different domain objects to handle, you might not want to couple these 2 different domains together and passing primitive params can be more beneficial.
Another case is when writing performance-first operations, creating objects could add redundant overhead.
i think everyone uses boolean param functions. IMO the suggestion you have given is awesome. The second best part was, it is not at all necessary to break down a function to too many small function, rather identify the functionality.
Can you also give some information about pure functions?
Clean Functions are the foundation of Clean Code!
Well explained, Daniel!
Amazing tips Daniel!
These are amazing tips.
Clean code is a great book one I've enjoyed thoroughly!
These tips are a great reminder of clean code lesr we forget after years of habit!
In all areas Cleanliness is next to Godliness
Clean code explained, nicely. I 'll leave only this as food for thought:
Regarding the fewer params in a method, sometimes it might not be the best practice.
Assume you are a consumer app and you have 2 different domain objects to handle, you might not want to couple these 2 different domains together and passing primitive params can be more beneficial.
Another case is when writing performance-first operations, creating objects could add redundant overhead.
i think everyone uses boolean param functions. IMO the suggestion you have given is awesome. The second best part was, it is not at all necessary to break down a function to too many small function, rather identify the functionality.
Can you also give some information about pure functions?
IMO "Instead of booleans, use Enums, making your code self-documenting."is
use two functions with descriptive names (follow the rule 2).
Usually when You have boolean as param in function You have inside "if" and if You replace it with enum logic will stay (some kind of "if")
By dividing into two functions
It will make your function logic simpler and function will be more SRP, and you will avoid complexity in function.
It helps with rule 1 - keep them smaller.
Of course follow also DRY for code that is the same in two new functions (maybe there is a smaller third one function inside)