Shulou(Shulou.com)06/03 Report--

This article introduces how long the method of Java code refactoring is long, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

How long is "long"?

100 lines? The tolerance for function length is too high! This is the key point that leads to the generation of long functions.

When you look at the specific code, you must be able to see the nuances. The key point is to make the task as small as possible, and this view also applies to the code. As the tolerance for code length decreases, the perception of code details will gradually increase, and you will be able to see all kinds of problems hidden in the so-called details.

"the smaller the better" is a goal to pursue, but without a specific number, there is no way to restrain everyone's behavior. So, usually, we still have to define an upper limit on the number of lines of code to ensure that everyone can follow this standard.

Statically typed languages like Java, which are less expressive, strive for 20 lines of code to solve the problem.

This is not a talking standard, we should turn it into an enforceable standard. For example, in Java, we can add line constraints to the CheckStyle configuration file:

In this way, the long function can be detected by executing the local build script before we commit the code.

Even with the upper limit of 20 lines, this has exceeded the understanding of many people, and the specific number of lines of the function can be determined according to the actual situation of the team.

It is not recommended to make this number very large, as I said earlier, if you put it on 100 lines, it basically doesn't make much sense and doesn't constrain the team.

What if the lines in the function are long? Should newline breaks also be inserted? If you insert a new line, you will increase the number of lines, and if you do not enter the new line, you should often move the horizontal scroll bar as you look at the code, counting by line of code rather than physical line.

Generation of long function

Limiting the length of a function is a simple and crude solution. The most important thing is to know that the long function itself is a result, if you do not understand the cause of the long function, it is still difficult to write clean code.

On the grounds of performance

Like C language, which is already a high-performance programming language today, at the beginning of its advent, it was questioned about its poor performance, especially function calls.

From the point of view of some people who write assembly language, calling a function involves the process of going into and out of the stack, which is obviously not as efficient as direct execution. This idea has evolved and spread to this day, and any new language will be questioned for the same reason.

So, in the eyes of many people, writing functions long is for the so-called performance. However, this view is untenable today. Performance optimization should not be the first consideration for writing code:

The dynamic programming language itself is constantly optimized, and the performance of both the compiler and the runtime will get better and better.

Maintainability should be given priority over performance optimization, when the performance is not enough to meet the needs, we will do the corresponding measurement, find the focus, and carry out specific optimization. This is more likely to lock in focus than to consider the so-called performance when writing code, and optimization makes sense.

tell in a simple , straightforward way

Write code to lay it out and list a little bit of what you think of. For example, the following code (if you don't want to read it carefully, you can skip to the back):

Public void executeTask () {ObjectMapper mapper = new ObjectMapper (); CloseableHttpClient client = HttpClients.createDefault (); List chapters = this.chapterService.getUntranslatedChapters (); for (Chapter chapter: chapters) {/ / SendChapter SendChapterRequest sendChapterRequest = new SendChapterRequest (); sendChapterRequest.setTitle (chapter.getTitle ()); sendChapterRequest.setContent (chapter.getContent ()); HttpPost sendChapterPost = new HttpPost (sendChapterUrl); CloseableHttpResponse sendChapterHttpResponse = null; String chapterId = null Try {String sendChapterRequestText = mapper.writeValueAsString (sendChapterRequest); sendChapterPost.setEntity (new StringEntity (sendChapterRequestText)); sendChapterHttpResponse = client.execute (sendChapterPost); HttpEntity sendChapterEntity = sendChapterPost.getEntity (); SendChapterResponse sendChapterResponse = mapper.readValue (sendChapterEntity.getContent (), SendChapterResponse.class); chapterId = sendChapterResponse.getChapterId ();} catch (IOException e) {throw new RuntimeException (e) } finally {try {if (sendChapterHttpResponse! = null) {sendChapterHttpResponse.close ();}} catch (IOException e) {/ / ignore}} / / Translate Chapter HttpPost translateChapterPost = new HttpPost (translateChapterUrl); CloseableHttpResponse translateChapterHttpResponse = null Try {TranslateChapterRequest translateChapterRequest = new TranslateChapterRequest (); translateChapterRequest.setChapterId (chapterId); String translateChapterRequestText = mapper.writeValueAsString (translateChapterRequest); translateChapterPost.setEntity (new StringEntity (translateChapterRequestText)); translateChapterHttpResponse = client.execute (translateChapterPost); HttpEntity translateChapterEntity = translateChapterHttpResponse.getEntity (); TranslateChapterResponse translateChapterResponse = mapper.readValue (translateChapterEntity.getContent (), TranslateChapterResponse.class) If (! translateChapterResponse.isSuccess ()) {logger.warn ("Fail to start translate: {}", chapterId);} catch (IOException e) {throw new RuntimeException (e);} finally {if (translateChapterHttpResponse! = null) {try {translateChapterHttpResponse.close () } catch (IOException e) {/ / ignore}}

Send untranslated chapters to the translation engine, and then start the translation process.

The translation engine is another service that needs to be sent a request in the form of a HTTP. Relatively speaking, this code is quite straightforward, when you know the logic I said above, it is easy to understand this code.

The main reason why this code is so long is that all the logic mentioned above is put there bluntly, where there is both business processing logic, such as sending chapters to the translation engine, and then starting the translation process, as well as processing details, such as converting objects to JSON and then sending them through the HTTP client.

From this code, you can see two typical problems with plain code:

Implement multiple business processes in one function

Put the details of different levels into a function to implement

Here, sending a chapter and starting translation are two processes. Obviously, this can be implemented in two different functions, so as long as we do the extraction function, we can disassemble this seemingly huge function. The scale of several functions will be much smaller, like the following:

Public void executeTask () {ObjectMapper mapper = new ObjectMapper (); CloseableHttpClient client = HttpClients.createDefault (); List chapters = this.chapterService.getUntranslatedChapters (); for (Chapter chapter: chapters) {String chapterId = sendChapter (mapper, client, chapter); translateChapter (mapper, client, chapterId);}}

The detached part is actually the process of packaging and sending the object. Let's take the sending chapter as an example. Let's take a look at the detached sending chapter:

Private String sendChapter (final ObjectMapper mapper, final CloseableHttpClient client, final Chapter chapter) {SendChapterRequest request = asSendChapterRequest (chapter); CloseableHttpResponse response = null; String chapterId = null; try {HttpPost post = sendChapterRequest (mapper, request); response = client.execute (post); chapterId = asChapterId (mapper, post) } catch (IOException e) {throw new RuntimeException (e);} finally {try {if (response! = null) {response.close ();}} catch (IOException e) {/ / ignore}} return chapterId;} private HttpPost sendChapterRequest (final ObjectMapper mapper, final SendChapterRequest sendChapterRequest) throws JsonProcessingException, UnsupportedEncodingException {HttpPost post = new HttpPost (sendChapterUrl) String requestText = mapper.writeValueAsString (sendChapterRequest); post.setEntity (new StringEntity (requestText)); return post;} private String asChapterId (final ObjectMapper mapper, final HttpPost sendChapterPost) throws IOException {String chapterId; HttpEntity entity = sendChapterPost.getEntity (); SendChapterResponse response = mapper.readValue (entity.getContent (), SendChapterResponse.class); chapterId = response.getChapterId (); return chapterId;} private SendChapterRequest asSendChapterRequest (final Chapter chapter) {SendChapterRequest request = new SendChapterRequest (); request.setTitle (chapter.getTitle ()) Request.setContent (chapter.getContent ()); return request

This code is not neatly handled, but at least it is a little more concise than before. Using only the simplest reconstruction technique of extracting functions, we split a large function into a number of small functions.

Long functions often imply a naming problem. If you look at the modified sendChapter, the variable names in it are significantly shorter than before, and the cost of understanding will be reduced accordingly. Because variables are in this short context, there will not be so many naming conflicts, variable names can of course be written shorter.

A key point of plain code is that it doesn't break down different things. If we measure this code from a design perspective, it is that the "separation of concerns" has not been done well, mixing things at different levels, not only different businesses but also different levels of processing. In the "Beauty of Software Design" column, I also said that the more concerns, the better, and the smaller the granularity, the better.

Add a little at a time

Sometimes, a piece of code doesn't start out long, like the following code, which handles errors accordingly based on the errors returned:

If (code = = 400 | | code = = 401) {/ / do some error handling}

Then, new requirements come, new error codes are added, and it looks like this:

If (code = = 400 | | code = = 401 | | code = = 402) {/ / do some error handling}

There are many opportunities for this code to be modified over time:

If (code = = 400 | | code = = 401 | | code = = 402 | code = = 500 | code = = 10000 | |) {}

When future generations see it, they want to swear. No code can stand this unconscious accumulation, everyone has done nothing wrong, but the end result is very bad. To fight this increasingly bad code, you need to know the rules of the Boy Scout:

Make the camp cleaner than it was when you came.

Robert Martin has borrowed it into the programming world, and we should see if our changes to the code have made the original code worse, and if so, improve it.

But the premise of all this is that you can see if your code is making the original code worse, so it's necessary to learn the bad smell of the code.

So far, we have seen several common reasons for code lengthening:

On the grounds of performance

tell in a simple , straightforward way

Add a little at a time

Code lengthening is an unconscious problem at all, and the people who write the code do not feel that they have broken the code. But as long as you realize that the long function is a bad smell, many of the following problems will naturally be discovered, and as for the solution, you have already seen that, in most cases, it is split into various small functions.

Summary

No one wants to read long functions, but many people inadvertently write long functions.

For the team, a key point is to define the criteria for long functions.

An overly broad standard makes no sense. To effectively control the size of a function, dozens of lines are already the upper limit of the standard, which is as low as possible.

The reason for the long function:

Performance as an excuse

Code tiling and direct narration

The most common reason for writing a function is long. The reason why the code is spread out there:

-write multiple businesses together.

-write different levels of code together. The root cause is that "separation of concerns" has not been done well.

Each person adds a little bit at a time

The main way to deal with it is to stick to the "Boy Scout rules", but the deeper support behind it is to have a deep understanding of the bad smell.

Write the function as short as possible.

On how long the Java code refactoring method is long to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.