Good developers are usually defined by code quality. In the software industry, writing good code means saving money on testing, updating, extending or fixing bugs. In this article, I will show you some real-life examples of techniques and ideas to help you clean up your logic code, refactor it, and make 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 cleaner code from now on.
What is refactoring and why do we need it?
Refactoring refers to methods and steps that help us write concise code. This is important for other developers who may read, extend, and reuse our code without much editing.
The following content will show you some examples of refactoring logic code to make it better.
Don't refactor production code without unit testing
My first piece of advice is to never start refactoring logic code without fully unit testing it. My reasoning is this: you'll end up with broken functionality that's hard to fix because it's hard to pinpoint what's broken. So if you're going to refactor it, start with tests. Make sure the parts you plan to refactor are covered by tests. PHPUnit code coverage analysis.
Start refactoring from the bottom of your code
Look at the picture below. This is a real hotel management system project that I found from Github. This is an open source project, but closed source projects would be terrible.
Example: Refactoring from the bottom
Look at this code, there are three levels marked in red. The lowest level should be the declaration surrounded by if/else in the first if condition. Usually, the lowest level is concentrated on a single logical processing and is easier to refactor.
Make your methods shorter, decompose them into smaller methods or configuration files/DB tables
Maybe here, we can refine it as below A private method:
#Make your methods shorter
The next point of depth will be uploading parameters and loading views. Now, let's look at the add() method after refactoring other parts. It becomes more concise, easier to read, and easier to test.
Example: Refactor the lowest level first
if statement insists on using curly braces
Most programming languages All support single-line if statements. Because it is simpler, some developers use it this way. However, it is not easy to read and can easily cause problems, because a blank line can interrupt the condition and cause a crash. 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 if the room exceeds 250, an error message will be returned. Here, 250 is considered a magic number. If you're not the developer writing this, it's hard to figure out what this number means.
Example: Magic Numbers
To refactor this method, we can indicate that 250 represents the maximum number of rooms. To replace the hardcoding, we can extract it into a variable $maxAvailableRooms . Now it becomes more understandable to other developers.
Example: Fix magic numbers
Don’t use else statements if you don’t really need to:
In the same availablerooms () function, you notice that if statement, where we can easily get rid of the else part and the logic remains consistent.
Example: Ignore else declaration
Use naming that represents your methods, variables, and tests
In the following example, you will find that the hotel management system has two methods: "index ()" and "room_m ()". For me, I can't figure out 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 can save you time and make your code more robust. Take a look at the example below and notice how it's easier to achieve the same result with less code, by using type hints.
Finally, I’d like to offer some quick tips for better coding:
● Use the new array form [] to replace the old array ().
● Unless it is important not to check the data type, use the === operator instead of ==.
● It is always a good idea to give public methods short, descriptive names. Private methods can use longer names because their scope is more limited.
● Only use generic names such as add () for methods that implement the interface, and use descriptive names such as addUser () or addDocument () for individual class methods.
● Remove unused methods from the class.
● Use the is/has prefix for functions that return values such as boolean: isAdmin ($user), hasPermission ($user).
● Always use access modifiers in class methods and properties.
● Pay attention to interface pollution: only use methods that are publicly available to users.
● Organize class methods with public methods at the top.
● Always apply the concept of single responsibility within a class.
The above is the detailed content of Necessary coding skills and thinking for senior PHP engineers. For more information, please follow other related articles on the PHP Chinese website!