Good developers are often defined by the quality of their code. In the software industry, well-written code means saving money on testing, updating, extending, or fixing bugs. In this article, I’ll show you some real-life examples of tips and ideas to help you clean up your logic code, refactoring it, and making it more robust and modular. These tips will not only help you refactor your old code, but also give you some good advice on how to write clean code from now on.

My official group click here.

What is refactoring and why do we need it?

Refactoring refers to the methods and steps that help us write clean code. This is important for other developers who may read, extend, and reuse our code without much editing.

The following will show you some examples of refactoring logic to make it better.


Don’t refactor your code in production without unit testing

My first piece of advice is never to start refactoring logical code without fully unit testing. My reasoning: you’ll end up with broken features that are hard to fix, because it’s hard to pinpoint what broke. So, if you’re going to refactor it, start with testing. Make sure that what you want to refactor is covered by the tests. PHPUnit code coverage analysis.


Refactor from the bottom of your code

Take a look at the picture below. This is a real hotel management system project I found on Github. This is an open source project, but closed source projects would be bad.





Example: Refactoring from the bottom up

If you look at this code, there are three levels highlighted in red. The lowest level should be the statement surrounded by if/else under the first if condition. Typically, the lowest level is focused on a single logical process, which is easier to refactor.


Make your methods shorter by splitting them into smaller methods or profiles/DB tables

Perhaps here we can refine it to a private method as follows:





Make your method shorter

The next in-depth point will be upload parameters and load views. Now look at the add() method after the rest of the refactoring. It becomes more concise, easy to read, and easy to test.





Example: Refactor the lowest level first


The if declaration insists on curly braces

Most programming languages support a single-line if statement, which is used by some developers because it is simpler, but it is not easy to read and is problematic because a single blank line can break the condition and cause a crash. Take a look at the difference between the following two examples:





Example: Use braces


Do not use magic numbers or magic strings:

In the next example, you notice that an error message is returned if the room exceeds 250. Here, 250 is considered a magic number. If you’re not the developer who wrote this, it’s hard to figure out what this number means.





Example: Magic number

To reconstruct this method, we can state that 250 represents the maximum number of rooms. Instead of hard coding, we can extract it into a variable $maxAvailableRooms. Now it’s easier to understand for other developers.





Example: Fix magic numbers


Do not use else declarations if you do not really need them:

In the same availablerooms () function, you notice the if declaration, where we can easily get rid of the else part, and the logic remains consistent.





Example: Ignore the else declaration


Use names that represent your methods, variables, and tests

In the following example, you’ll see that the hotel management system has two methods called “index ()” and “room_m ().” For me, I don’t know what their purpose is. I think it should be easy to understand if their names describe themselves.





Example: Bad method naming


Take full advantage of the capabilities of your programming language

Many developers do not take advantage of the full capabilities of the programming language they use. Many features save you time and make your code more robust. Take a look at the example below and notice how it is easier to achieve the same result with less code by using type hints.









Finally, I’d like to offer some quick tips on better coding:

  • Replace the old array () with the new array form [].
  • Unless it is important not to check the data type, use the === operator instead of ==.
  • It’s always a good idea to give short, descriptive names to public methods. Private methods can use longer names because they are more limited in scope.
  • Use generic names such as add () only for methods that implement the interface, and descriptive names such as addUser () or addDocument () for individual class methods.
  • Remove unused methods from the class.
  • Use is/has prefixes for functions that return Boolean values, etc. : isAdmin ($user), hasPermission ($user).
  • Always use access modifiers in class methods and properties.
  • Note interface contamination: Use only methods that users can use publicly.
  • Organize class methods where the public methods are at the top.
  • Always apply the concept of a single responsibility in a class.
  • I hope the above content can help you. Many PHPer will encounter some problems and bottlenecks when they are advanced, and they have no sense of direction when writing too many business codes. I have sorted out some information, including but not limited to: Distributed architecture, high scalability, high performance, high concurrency, server performance tuning, TP6, Laravel, YII2, Redis, Swoole, Swoft, Kafka, Mysql optimization, shell scripting, Docker, microservices, Nginx, etc.