What are some common code smells and how do you refactor them using clean code techniques?

Long methods not only impede the readability and understandability of code but also pose challenges to maintainability and collaboration within a development team. As codebases grow in complexity, the ability to maintain and enhance functionality becomes crucial. Long methods hinder this process in several ways. - Maintenance Nightmare - Collaboration Challenges - Testing Complications - Adaptability and Extensibility

Extract methods: Break up long methods into smaller, focused methods that each do one thing Replace temp with query: Instead of using temporary variables, extract calculations into methods Introduce parameter object: If a method has a lot of parameters, consider creating a parameter object // Before public void longMethod() { // lots of code... } // After public void method1() { // extracted code } public void method2() { // extracted code }

A lengthy method often indicates a lack of abstraction, which is better than poor abstraction. It's sometimes better to inline poorly abstracted methods into a larger one to grasp the entire code properly. To refactor lengthy methods, I'd recommend to: 1. Identify the method's hidden abstractions. 2. Write tests for all method paths to prevent regressions. 3. Restructure the method by grouping logically cohesive blocks while adjusting variable declarations for clarity and proximity to their usage. → Your tests validate your assumptions during this process. 4. Refactor these blocks further into separate methods or even classes, rigorously testing them while removing the original method's obsolete tests as needed.

Common code smells indicate deeper issues in the codebase and can be addressed using clean code techniques: - Duplicated Code: Extract repeated code into a single method or module. - Long Methods: Break down into smaller, single-purpose functions. - Large Classes: Split into smaller, focused classes using the Single Responsibility Principle (SRP). - Long Parameter Lists: Use parameter objects or builder patterns. - Feature Envy: Move methods to the class they interact with most. - Comments: Refactor code to be self-explanatory through clear naming and structure. These techniques improve readability, maintainability, and scalability.

Make use of IDEs like VS Code, IntelliJ, etc., to REFACTOR your LONG METHODS into more meaningful short methods with the EASE of a button click. If the parameters of the methods exceed more than 3 put them into a collection like MAP or LIST and then iterate them while using inside the method. The short methods can SAVE YOU TONS OF TIME to write a Unit Test.

When a class accumulates too many responsibilities, fields, or methods, it becomes a breeding ground for complexity, making it harder to maintain and extend. This code smell is often an indicator of a violation of the single responsibility principle and can hinder the overall design and flexibility of the software.

Extract class: Move cohesive sets of fields and methods into new classes Extract subclass: If part of a class operates on a subset of features, extract those into a subclass Extract interface: Define an interface that large classes can implement to divide responsibilities

When refactoring large classes, I would address two common issues: lack of cohesion and excessive responsibilities. If a class lacks cohesion, start by identifying clusters of methods that don't use all instance variables, suggesting multiple logical classes within one file. Then, isolate these clusters using metrics like LCOM4 and extract them into separate classes to improve cohesion. Alternatively, if the class has too many responsibilities, analyse which groups of public methods clients consistently use together. These groups are candidates for extraction into separate classes, reducing the original class's responsibilities and improving its clarity and maintainability.

The best way to address the large class code smell is to split the class into multiple smaller classes, each responsible for a distinct part of the class's overall functionality. This approach aligns with the Single Responsibility Principle (SRP), which states that a class should have only one reason to change. By decomposing a large class into more focused classes, you improve the code’s readability, maintainability, and testability. Each new class will handle a specific aspect of the original class's functionality, making the system easier to understand and extend.

Make it a priority to find out time for identifying those large classes in your codebase. Remember, the process of refactoring these large classes is not just being a technical task, it’s a fundamental practice in preserving the integrity of your code. Approaches like extract class or move method outside the class aren't merely for tidying up, they’re about refining the overall structure, enhancing the cohesion, and aligning each element more closely with its intended function. This effort does more than just simplify code management; it equips the code to be more flexible and responsive to the dynamic and evolving needs of game development.

Extract method: Move duplicated code into a shared method Pull up method: If subclasses have duplicate code, move it into the superclass Form template method: Define an algorithm skeleton in the superclass with steps that subclasses override

I don't think duplication always comes from laziness; often, it creeps into the codebase because it becomes too large and is not perfectly maintained by the architects or lead positions. But nowadays, we have a lot of software that can help us reduce duplicate code. Importantly, these tools should be set up early in the project's state.

When dealing with code duplication, I prioritise clarity and purpose over strictly adhering to the DRY (Don't Repeat Yourself) principle. In this context, evaluating behavioural patterns rather than identical sequences of instructions is crucial, as merging them prematurely can lead to confusion and obscure intent. It's often beneficial to write similar code blocks repeatedly (WET—Write Everything Twice) until distinct patterns emerge, justifying their consolidation into cohesive, reusable concepts. While duplicated code is often frowned upon, avoiding convoluted abstractions is even more critical as they hinder readability and logical structure.

Duplicated code can also creep in when a developer lacks knowledge about existing codebase or functionality that could be reused. In addition, when multiple developers work on similar features in parallel, they may end up writing similar code blocks that could have been shared.

If you ENCOUNTER duplicated code issues, the ROOT CAUSE often lies elsewhere: - It could be the COMPLEXITY of the project to have a MULTI-MODULE mono-repo - It could be due to HARDCODED values slowly creeping in as the system mature - It could also mean LACK of CUSTOM LIBRARIES to your organization's needs Resolve the ROOT of the DUPLICATED CODE to have a better SYSTEM.

Yeah, definitely, even if I did not see primitive obsession as often as the other problems. By refactoring away from primitive obsession, developers contribute to code that is not only more readable and expressive but also better equipped to handle changes and extensions in a systematic manner. This shift towards richer abstractions enhances the overall quality and maintainability of the software.

Replace data value with object: Turn primitives into tiny objects to encapsulate behavior Introduce parameter object: Instead of passing groups of primitives, pass an object Replace array with object: Arrays of primitives can often become classes with named accessors

Primitive obsession means using basic data types to represent domain-specific concepts. While initially straightforward, relying solely on primitives can lead to inconsistencies and vulnerabilities. For instance, using an integer for monetary amounts may overlook constraints like negativity. By encapsulating these concepts into dedicated "value objects," such as a Money class, you can: 1. enforce rules (e.g. only accept positive amounts) 2. enhance clarity by explicitly defining types 3. streamline maintenance (e.g. adding currency to the Money type without altering all method signatures). This approach facilitates refactoring, improves code robustness and maintains a clear representation of domain logic throughout the application.

?? Is your code drowning in primitive types? When you rely too heavily on primitive types like int, string, or boolean to represent complex ideas, your code starts to lose its readability, validation, and flexibility. This is called "primitive obsession"—a common code smell that can make your code feel like a tangled mess. But there’s a way to sail clear! ?? ?? Group related parameters using the "introduce parameter object" technique. ?? Wrap primitives in meaningful classes to boost abstraction. ?? Enhance readability with better encapsulation. Are your primitives sinking your project?

Keep it real; the problem can not be easily thrown into a solution that fixes all problems. Of course, a cleanly implemented polymorphic class structure is most often the better solution, but sometimes in small-scale projects, you can easily use a switch statement or, even better, a lookup table. Just think in the scope of something like JavaScript or Python. Simple problems often need simple solutions.

Extract method: Hide switch statements in well-named methods Move method: Put switch statements in the class where polymorphic behavior is used Replace conditional with polymorphism: Make each leg of a switch a subclass method that overrides a base method

When updating switch statements, especially with enums, the goal is to reduce repetitive code and avoid mistakes when changing enum values. One good way to do this is by using polymorphism. Instead of a switch statement, you can replace each case with a different implementation of the same interface. This makes method calls dynamic and removes the need for explicit switches, which helps prevent missing cases. Another approach is to use a Dictionary. Enums are the keys, and the corresponding switch cases are the values. This offers a more flexible and easier-to-maintain alternative to traditional switch statements.

?? Are you unknowingly steering your code into dangerous waters? ?? Imagine a ship’s captain constantly borrowing another vessel's crew to navigate. It’s a sign of trouble, right? The same goes for code. One common code smell, feature envy, occurs when a method is too dependent on another class’s data. This disrupts the balance, making your code fragile and hard to maintain. Here’s how you can refactor: ?? Move Method/Field: Relocate it to the class it uses most. ?? Extract Method: Create a new method in the right class. ?? Rebalance Responsibilities: Ensure each class pulls its own weight. ? Are you ready to captain your code with clean techniques? Or will you let it drift?

?? Is your code making your project sail off course? ?? Switch statements—useful or a sinking ship? While they might seem handy, they’re often cumbersome and prone to errors, much like navigating choppy waters without a compass. Here’s how to steer clear: ?? Replace conditionals with polymorphism: Craft subclasses that handle specific tasks. ?? Swap type codes for subclasses: Make your code modular and flexible. ?? Adopt the state/strategy pattern: Let objects take control. Do switch statements anchor your code in place, or should you set sail for a cleaner approach? ?

Did you know your code can get seasick too? Imagine your code as a ship's crew. If a method named FeatureEnvy spends more time interacting with another class, it's a sign of poor distribution of responsibilities: ?? Move Method/Field: Assign FeatureEnvy to the class it frequently uses. ?? Extract Method: Create a new role in the appropriate class for tasks FeatureEnvy performs, enhancing clarity. ?? Clear Communication: Ensure each part of your code communicates effectively, like well-coordinated ships. Is your code sailing smoothly, or is it time to clean up? Are we complicating our journey with unnecessary dependencies?

Move method: Put methods in the class that contains most of the data they operate on Extract method: If only part of a method operates on another class, extract that part into the other class

Maintaining code quality extends beyond cleanliness; comprehensive documentation is essential. Well-documented code acts as a roadmap, easing understanding, maintenance, and extension. Clear comments, README files, and thorough documentation enhance project longevity. While new technologies enhance efficiency, stability contributes to sustained success. Successful development hinges on finding harmony between innovation and stability.

Here's my top 3 cause of decreased productivity: ?? Side effects If the behavior of your function depends on something outside of it, you'll have a hard time debugging. Use immutable objects & parameters to make sure given the same input produces the same output NB: Side effects may be necessary (e.g. database connection) ?? Lack of Tests When you read a codebase you don't understand, you're afraid to make changes. Tests documents and enforce code expectations (thus limits regressions). ?? World parameters When you inject "everything" in your sub-code, then you'll leave developers the opportunity to do "anything". Prefer only injecting instances of dependencies over parameters to construct dependencies internally.

Naming: Use intention-revealing names for variables, methods, classes. Avoid disinformation. Functions: Keep them small, with as few arguments as possible. Have no side effects. Comments: Minimize comments by making code self-explanatory. Use them to explain why, not what. Formatting: Maintain consistent indentation, limit line length, use whitespace to separate concepts.

Maintaining a clear, current, and easily accessible coding standard is vital. One of the most effective methods to achieve this is by forming a committee comprising representatives from various tech teams. To increase awareness, regularly share code smell statuses from SonarCloud (or whichever tool/service you are using) in your team's communication channel. This ensures visibility for all members and prompts immediate corrective actions from the developers.

Use AI tooling. Github Co-pilot, Codecov, stability.ai, Code Llama, WizCoder etc provide capabilities to review the code for conciseness and accuracy, provide documentation, assist with unit tests and more. While these activities were expected to be a skill of the trained and expert software developer, it is slowly becoming a commodity offering. While the quality and correctness are still a challenge it will only get better with time and more players entering the arena. It is worth leveraging these tools to reduce the burden on your talent.