I’ll start by providing you exactly what you came for: the rules of thumb.

Are you curious about why these heuristics are useful? Then read the additional information included after the list.

---

12 Heuristics for Beginners to Become Refactoring Experts

Let’s dive headfirst into the matter. This list is a mix of heuristics I always have in the back of my mind when I venture into a refactoring session.

1. Is your class’ list of parameters starting to grow too big? Then it’s likely doing too much. Its responsibilities are unclear and perhaps painful to test and debug. It’s a prime candidate for refactoring.
2. Do you have methods inside classes that only use one of the class dependencies? You better pull that method into a class of its own — even if that class will only consist of a single method.
3. Is your method doing two different things depending on a boolean parameter value? Why not just create two different methods with clear responsibilities?
4. Is your method branching over a value? Say, for instance, you’re checking the type of an object and perform different operations based on its type. This is a great time to turn your if-else or switch into a dictionary or map.
5. Do you use if-else or switches extensively throughout your code? Try using polymorphism instead and apply battle-tested design patterns like Strategy, Mediator, etc.
6. Does your class constructor or method take a “magic” number or string? That is an arbitrary value representing some intrinsic business value. Replace the magic with enums.

#computer-science #clean-code #programming #software-development #software-engineering #visual studio code