Good developers are defined by the quality of their codes. In the software industry, writing good code means saving the money that may be invested in testing, updating, extending or fixing bugs. In this article, I will show you real-life examples of some techniques and ideas that will help you to clean up your legacy code and refactor it to make it more robust and modular. These techniques will not only help you to refactor your old code but will give you great ideas as to how to write clean code from now on. What Is refactoring and why do we need It? Refactoring refers to techniques and steps that help you to write clean code. This is important for other developers, who then will be able to read, extend and reuse the code without the need to edit much. The next lines will show you some examples of refactoring a legacy code and make it better. Never refactor a production code that does not have unit tests My first advice is to not ever start refactoring a legacy code, which does not have proper unit tests. I guess the reason is obvious: You will end up with broken functionalities that are difficult to fix because you won’t be able to figure what’s broken. Therefore, if you need to refactor it, start with testing it first. Make sure the part you are going to refactor is covered by the tests. Check . PHPUnit code coverage analysis Start refactoring from the deepest point of your code Take a look at the next picture. This is a real project for a hotel system that I found on Github. This is a real open source project so the closed source can be worst. management example: refactoring deepest points first As you can see in this method, there are three levels marked in red. The deepest point should be the nested if/else statement inside the first if condition. Usually, the deepest point is focusing on a single logic which makes it easier to refactor. Make your methods shorter by dividing them into smaller methods or configuration files/DB table Maybe, in this case, we can extract it to a private method as following: make your functions shorter The next deepest point will be fetching the post data and loading the views. Now, take a look at the method add() after refactoring the other parts. It is much cleaner, readable and testable. example: refactoring deepest points first Always use {} within if-statements Most of the languages support one line if-statements and some developers use it because it is simple, however, it is not readable and it’s easy to cause problems since only one empty line can break the condition and start crashing. See the difference between the two examples: programming example: use curly braces Do not use magic numbers or magic strings: In the next example, you notice if rooms are more than 250, it returns an error message. In this case, 250 is considered as a magic number. If you’re not the developer who wrote it, it will be hard to figure out what it represents. example: magic numbers In order to refactor this method, we can figure out that 250 is the maximum number of rooms. Therefore, instead of hardcoding it, we can extract it to variable $maxAvailableRooms. Now, it is more understandable to other developers. example: fix magic numbers Do not use else-statements if you do not need to: In the same function availablerooms() you notice the if-statement, in which we can easily get rid of the else part and the logic will still be the same. example: ignore else statement Use meaningful names for your methods, variables and tests In the following example, you can see that there are two methods from the hotel management system called “index() and room_m()”. For me, I cannot determine what their purposes are. I think it would be easier to understand if their names were descriptive. example: bad methods names Use the maximum capabilities of your programing language Many developers do not use the full capabilities of the programming language they use. Many of these features can save you a lot of effort and make your code more robust. Take a look at the next examples and notice how it can be easy to achieve the same result with less code by just using the type hinting. I would like to end with a few more quick tips on better coding: Use a new array form [ ] instead of the old one array(). Use === operator instead of == unless it is important to not check for the dataType. It is always a good idea to give public methods short descriptive names. It is ok for private methods to have longer names as they have a limited scope. Only use general names with methods that implement interfaces example add() and use descriptive names for single classes methods addUser() or addDocument(). Remove unused methods from your classes. Use prefix is/has with functions that return boolean ex: isAdmin($user), hasPermission($user). Always use access modifiers in class methods and properties. Be careful with interface pollution: Only use methods that users can use publicly. Organize classes methods where public methods are on the top. Always apply the single responsibility concept to your classes. _Code smells are a set of common signs which indicate that your code is not good enough and it needs refactoring to…_hackernoon.com Write clean code and get rid of code smells with real life examples **More to Read:**- - - Software Architecture — The Difference Between Architecture and Design Software Architecture: Architect Your Application with AWS Write clean code and get rid of code smells with real life examples
