Method of code refactoring -- Analysis of method refactoring

5 Line code , Can let wechat small program on the shelf to their own APP in | Register and send it to Dajiang 、 Huawei 、 Cherry keyboard ！>>>

Method reconstruction analysis

The method of code refactoring —— Method reconstruction analysis

Intro

Want to write better code , You need to be alert to bad smells in your code , Today I want to write an article about how to analyze whether your method needs to consider refactoring

A method usually consists of three parts , Input (Input), Output (Output), Method body (Method Body), We will analyze whether a method should consider refactoring from these three aspects

Input

Method input is the parameter of the method , Generally speaking, the parameters of a method can be basically controlled in 7 Within a （ For reference only , You can measure it by yourself ,SonarQube The default method has up to seven parameters ）, If your method has too many parameters , You may need to consider refactoring a method parameter , The usual practice is to encapsulate a separate model, Parameters as model Properties of .

Take a common example , Like a news list API, It can be very simple at first , Just one lastId, One count Two parameters , But as business needs increase , Many other parameters may be added , For example, the front end provides a keyword Full text search , Provide a sortBy Sort , Match the news headlines , Author name matches , Classification matching , Filter according to the release time and so on , In the end, there may be many parameters for this method

Usually I add a new one XxxRequest Of model, Then replace the method parameter with this model, Then designate [FromQuery] That's all right. , You can compare the difference before and after a modification , Is the latter way more refreshing

Task<IActionResult> List(int lastId, int count, string title, string author, string keyword, int categoryId, string sortBy, DateTime? beginTime, DateTime? endTime)

Task<IActionResult> List([FromQuery]NewsListQueryRequest request)

Output

Output Is the return value of the method , Return as many specific types as possible , Try to avoid using Tuple Other types , The return value of the method should have a clear meaning

Use specific Model Instead of Tuple Return value , Especially some public Of , Methods to be accessed externally should return specific types , although C# 7.2 Started to support named tuple, It's going to be a lot more friendly than before , Support to tuple Specify a name , But it's just compiler level , Actually, it's still Item1,Item2 ..., It is recommended to use specific ones model, More clearly

Body

Usually a method is not too long , I saw a group of friends make complaints about more than 2000 ways in the group , This is a disaster to maintain , Don't make a method too long , Keep the cube simple , Some general logic goes through Filter Or combine AOP To achieve

Sonar There is a way to analyze the complexity of a method , Officially called Cognitive Complexity

A brief introduction , In code if/switch/for/foreach/try...catch/while Will increase the complexity of the method , If there is a layer of nesting, the complexity will be increased 1, Sonar The default complexity of a method cannot exceed 15

Here are a few simple examples ：

The complexity of the following method is 3, There are three if(else) Branch