Check out some of the code that has not been very good (Part 2)

The following article will continue to point out some possible cases when writing PHP code in general, Laravel in particular. These may be basic logical errors, improper function usage; Or simply convention errors are not worth it.

In addition, a few examples related to JS in general and Jquery in particular will be mentioned.

Part 1 of the series: A look at some of the code is not very good (Part 1)

10. Use multiple isset() functions at the same time

Instead of writing the following:

Can be combined into a function call:

11. The assertion order was not right when writing Unit Test

Testing whether $a is an instance of A::class should be performed before testing functions inside A::class .

12. Use the isset() function to check for null with the array access syntax on IlluminateHttpRequest (Laravel)

When sending a request with a = null , the above function will still display the result inside if condition, instead of else .

To be able to access the properties of the Request object with array syntax, the Request class must implement the ArrayAccess interface.

Therefore, when using isset() on $request['a'] , it is essentially calling the offsetExists function implemented in class IlluminateHttpRequest .

This function only checks for the existence of a in the incoming request, not if the value of a is null.

This is a confusing point when the default isset() function checks whether a variable exists and is not null.

Therefore, be cautious when using array syntax on the IlluminateHttpRequest : if (isset($request['a']) && !is_null($request['a'])) object if (isset($request['a']) && !is_null($request['a'])) ; or convert to array form using isset() function

13. Using magic method bluff

The code above is a typical example when you want to access a value in a request sent by key, based on the magic method.

In this example, the data submitted is a request containing information about the title ( title ) and content ( content ) of a certain post .

Access through the title key is quite smooth, although this is not recommended and many risks. You can refer to the following article: Laravel requests … DEADLY flexible

However, the problem will be more visible when using the magic method in the code below:

$content = $request->content;

This line of code instead of getting the value of the input content box submitted, it prioritizes the value of the protected $content attribute in the previous Request class. Therefore, lead to undesirable results.

Therefore, in addition to not naming the key in the request that matches the properties of the Request class, the magic method should be restricted to being used to access a value in the Laravel request.

14. Name the function does not start with a verb

A function usually represents a certain action / function. Therefore, the function name should begin with a verb.

Instead of

Consider changing to:

15. Array name is not in plural form

Convention naming arrays in plural form is not required in some cases. However, naming in the plural will make the code a bit easier to read.

16. Unreasonably named route

Calling and using the route according to the corresponding route name:

Instead, you can shorten:

17. Duplicate jQuery selector

In addition to some special cases, the code above is not optimized when performing the same element search twice. Can consider revising as follows:

18. Access attribute may not exist in an object

In the above example, the error when showBarError() Ajax request will be displayed through the showBarError() function. This function takes a parameter as the value of the bar attribute in the errorResponse.foo object.

If the error response is returned as an object with the same structure as above, the error display will have no problems.

However, in practice, especially in the case of error handling, the returned data may be unpredictable and unpredictable. Therefore, it is advisable to consider adding test conditions before accessing the properties of an object or using try-catch syntax.

19. Initializing unnecessary values

Initializing the bar initial value in the above example is not necessary because the value of the variable foo always overwritten in the if-else below. Depending on the actual problem, it can be corrected in either of the following directions:


However, in some special cases, such as the isTrue() function throws an exception, initialization of the initial value becomes necessary.