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

This article mainly introduces "how to write hot GitHub code". In daily operation, I believe many people have doubts about how to write hot GitHub code. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "how to write hot GitHub code". Next, please follow the editor to study!

1. Name variables in a way that is easily confused

The less we type, the more time we have to think about issues such as code logic. The following figure shows that the variable is named "a", and no one knows what it means. On the contrary, naming it "age" is an ordinary thing.

two。 Variable / function mixed naming style

Celebrate for something different. Most people will set the variable name and function name to the same format, but using different styles can reflect not only our coding ability, but also our naming ability, killing two birds with one stone.

3. Don't write notes.

At this point, the author gives an official complaint: no one will read your code anyway, so why write comments? I take it for granted that commentators are a sign of a lack of confidence in their own code, aren't they? (manual dog head

4. Write notes in your mother tongue

If you violate the "no comment" principle, at least try to write comments in a different language than the one you use to write code.

For example, developers whose mother tongue is English can annotate them in Japanese, Korean or Russian so that they can learn a foreign language while writing code. Our domestic developers can also try to write notes in some small languages, after all, we are a mysterious group of people.

5. Mix different formats as much as possible

Celebrate for something different. If it conforms to the code specification, mix different formats as much as possible, such as single and double quotes in the example.

6. Write the code on one line as much as possible

I believe everyone has seen those "one-line code xxx" iron son, why do they think one line of code implementation is so cool, we can not write one line?

7. Don't deal with errors

Whenever a mistake is found, there is no need to let anyone know about it. No log, no error pop-up box.

8. Extensive use of global variables

The author said that this is in line with the principles of globalization, there is reason, there is a pattern.

9. Build variables that you don't need.

Just in case. Although you can't use it now, what if it works later? abc is an iron triangle and can never be divided.

10. If the language allows, do not specify types and / or do not perform type checking.

No type is the best type.

11. You should have code that doesn't work.

As a "Plan B", you need to have some code that doesn't work, which means you're doing extra thinking.

twelve。 Triangle rule

If writing code is an art, then the triangle rule is obviously the most artistic design.

13. Mixed indentation

Avoid indentation because they make complex code take up more space in the editor. If you don't like avoiding them, make a mess and use a mixed indentation strategy. (this one really won't wash.)

14. Don't lock your dependencies

Update each newly installed dependency in an uncontrolled manner. Why do you insist on using the past version? let's use the most advanced library version.

15. Long functions are better than short functions.

Don't divide the program logic into blocks of code. What if the search for IDE stops and you can't find the file or function you need?

10000 lines of code in a file are OK

A function body 1000 lines of code is OK

Handle many services (third-party and internal, there are also some tools, database handwritten ORM and jQuery sliders) in a 'service.js'? It's also OK's.

16. Don't test your code

This is repetitive and unnecessary work.

17. Avoid uniform code style

Write the code you want, especially if there are multiple developers on a team. This is a principle of "freedom". Not special, how to reflect their own maverick!

18. No README documentation is required to build a new project

We should keep the good habit of not writing README from the beginning (there is no README in this GItHub project, and the author is the unity of knowledge and practice).

19. Save unnecessary code

Don't delete unused code, comment it out at most. After all, every line of code we have written is the sweat we have ever flowed. If we delete it, how can others know that we have written it?

Play and play, don't joke about work

There is a saying widely spread: "the code is for people to read, by the way, let the machine execute."

I think it makes a lot of sense, although the code is a machine language, but the use and debugging is still carried out by people, so we still need to meet the needs of humanization and design ideas to the greatest extent.

At this point, the study on "how to write hot GitHub code" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.