Think more about less coding: More code, more problems

Abstract:Ed Finkler is a PHP, Python, and JavaScript programmer. Has many product development experiences, such as spaz, an open-source Weibo client desktop and WebOS. He summarized some very useful coding codes and shared them with everyone.

Source article from: http://www.csdn.net/article/2012-12-13/2812774-More-Code-More-Problems

About a year ago, I wrote some PHP Web programming code-microphp manifesto. But I found that there are some common programming/coding rules between different languages, which may be some of my gains after I am familiar with various programming languages.

The following are some of the rules I have summarized and should be kept in mind in practice.

Learning languages rather than frameworks

I like PHP, Python, and JavaScript, and I like to use them to do something. However, I am not a symfony, Django, or jquery developer.

I think there is a big difference. A person may become a jquery programmer, not a javascript programmer, or a Django programmer rather than a Python programmer. In practical applications, there are indeed many valuable and useful tools and frameworks, but if I only know how to use a framework, the idea I want to express is that using only suitable tools at work will actually impose some limitations on tasks. In my experience, some complicated full-Stack) the framework is not a very suitable tool, especially in terms of flexibility and performance.

Concentrated learning a language will make programmers more flexible. A full-stack complex framework can help me quickly build a product, but when I need a solution that is not within the framework, it will become a kind of damage. I often use the plug and pray methods for development. When I find that a library or plug-in can meet my needs, I will apply them to the product. This may make the application quickly available, but it will leave many obstacles in the future.

In addition, learning the full stack framework is as complicated as learning new languages. They generally have complex architectures and terminologies, and some parts are not applicable to other frameworks and tools. I would rather spend time learning more about the language itself and apply my skills to other languages or libraries.

Build small modules

Some small unit codes are very nice for programmers, because the smaller the unit code, the easier it is to understand and make it difficult to get worse, it is very important to restrict the compilation of lengthy and complex code.

So we can build some small modules with a purpose-to be as close as possible to the demand goal. They should be independent blocks to solve some problems, but when they are combined, they can solve many large and complex problems.

It is also very easy to fix bugs like these simple module codes. Because these individual blocks are easy to understand, they will be used at a glance. If the module is self-contained, testing will be easier.

The less code the better

To use Biggie smils:"The more code, the more problems".

Everyone likes to manage less code. It is estimated that everyone has had this experience. when reviewing the Code of a function module, if the code is too messy, the first impression is definitely not good. On the contrary, if the code of this module is concise and clear, you will be very happy. More commonly, the more code, the more difficult it is to manage: the longer it takes to search the code base, the longer it takes to view file navigation, and the more difficult it is to trace and execute.

Those huge libraries and long code seem to overflow people's brain buffer. I am very upset when I am tracking a long source code or performing the function of jumping several source files. This is why I like the editor that colors the syntax and keeps spaces consistent.

In addition to managing less code, I also support developers to simplify code as much as possible. The Code that a programmer uses for an application is not only part of the code written by himself, but also each line of code in the application. This means that you are responsible for the bugs or security vulnerabilities in these applications.

Will you use code that you do not understand in the program? This does not mean that I never use others' code-Frankly speaking, there are many excellent programmers in the world, but you must understand the code when applying others' code, because each line of code in the application is very important. Never forget to think about coding,There should be a lot of thinking behind writing the least code, so it won't bring unnecessary trouble to yourself.

Write simple and useful readable code

Write easy-to-understand code and think less about code. This way, a function can be completed quickly and productivity will be improved.

Of course, I also want the code to be verifiable. And I always think that simple and modular code is easier to be tested.

Another feature that the Code should possess is readability. The Code should be concise and clear, and the meaning should be clear. When writing code, I will think about how long it will take for other programmers to understand it at first glance. Or can I see it in a month or two? As the well-known programming proverb:Any fool will write code that can be understood by machines. Only good programmers can write code that humans can understand.. The less time I try to find out how they work, the more things I do.

But few people stick to these rules. If I say yes, I must be lying. Sometimes I am also very lazy, or even due to time constraints, I will write some complex, hard-to-understand code or use a library without review to implement a function. It is difficult to write simple and clear code in the short term-it requires more discipline and constant technical evaluation. In particular, time-sensitive projects will be more difficult to implement.

However, when you take the time and energy to do this, you will find that you are not only helpful to yourself, but also benefit other team members.