preface

Yesterday, I mentioned that I can’t write code at all, so even though I am busy with business and driven by pressure today, I still want to finish reading some new knowledge, summarize some new knowledge and improve myself.

Read a few pages of “moat of life”, a lot of things are not remembered, do not have the ability to understand. But there’s one thing I seem to understand.

When doing something, smart people think about the next three to five years, great people think about the next five to ten years, and really great people think about the next ten to twenty years.

The code you’re typing now may not be worth a dime ten years from now, but it’s never out of date to think about it.

Bad taste

With some confusion before, I turned out the books hidden deep in the pile of books and saw several concepts. In my programming career for several years, I am more and more able to understand them.

First of all, there’s a gut feeling to good code, not logic. This is just a logical generalization of intuition as much as possible. Provide some direction for thinking, not mechanically.

Overlong function

The longer the function, the more hair-raising it is. The longer the function, the harder it is to understand. There’s a principle in the book that really hits home. Every time you want to write some comments, you’ll probably find a new function. That is, we should use a good function name to express what a piece of code does. Even in the book Refactoring it is suggested that even if there is only one line of code underneath a comment, that line should be distilled into a function. As long as the function name explains its purpose, it should be done without hesitation.

So what is the right time?

  1. One is the comments in the function mentioned above
  2. Conditional expressions and loops are also often refined information. In fact, it’s a combination ofifInside the execution logic andelseThe execution logic inside is distilled into a function. The authors call itDecompose Conditional expression. If it’s a loop you just take the loop and the logic inside of it and divide it into a function.

Too long parameter column

At the beginning of my internship in Shanghai, I often struggled with whether the parameters passed from the front end to the back end should be accepted by objects or by parameter lists when writing code. Now I don’t get caught up in that. One of the things I could sense at the beginning of Refactoring was that code was good and bad, but that code was good and bad was intuitive, there was no absolute logic.

An excessively long argument column may cause all objects that call the function to have to be modified again when it needs to be modified. If the argument column is too long, you can use Preserve Whole Object to create a parameter Object, also known as a query Object.

However, things are not absolute. This can lead to excessive dependencies. For example, when calling a function that takes an object as an argument and needs to rely on that object, there is an additional procedure for constructing that object in the upper function. If you don’t want to construct a complex object, consider structuring the object, using parameter passing. The other way, of course, is to build objects without having to write many, many lines of set.

Work pressure is a little bit, only a little study time every day. However, I believe that this difference will bring us a change in the level of compound interest over the next year.

About writing

From now on, I will write an article here every day, with no limit on subject matter, content or word count. Try to put your daily thoughts into it.

If this article has helped you, give it a thumbs up and even better follow it.

If none of these are available, write down what you want to say when you finish reading? Effective feedback and your encouragement are the biggest help to me.

And I’m going to pick up my blog. Welcome to visit and eat watermelon.

I’m shane. Today is August 28, 2019. Thirty-fifth day of the hundred day writing project, 35/100.