About a year ago, I wrote some PHP web programming guidelines - the MicroPHP Manifesto. But I found that there are some common programming/coding rules between various languages. This may be something I gained after becoming familiar with various types of programming languages.
Here are some rules that I’ve picked up and should be kept in mind in practice.
Learn the language not the framework
I like PHP, Python and JavaScript and making stuff with them. But I am not a Symfony, Django, or jQuery developer.
I think that makes a big difference. It's possible to be a jQuery programmer instead of JavaScript, and it's possible to be a Django programmer instead of Python. In real applications, there are indeed many valuable and very practical tools and frameworks, but if I only know how to use one framework, the point I want to make is that using only the right tools for the job actually brings some limitations to the task. , you can check it out to see the tools you use and the framework you use. From my experience, some complex full-stack frameworks are not very suitable tools, especially in terms of flexibility and performance.
Concentrating on learning a language will make programmers more flexible. Full-stack complex frameworks can help me build a product quickly, but when I need a solution that is not within the scope of the framework, it turns into a disservice. I often take a "plug and pray" approach to development, and when I find a library or plug-in that meets a need, I implement it into the product. This might get the app out quickly, but leaves a lot of hurdles down the road.
Furthermore, learning a full-stack framework is as complex as learning a new language. They often have complex architecture and terminology, and some parts don't apply to other frameworks and tools. Of course, frameworks also have many benefits, but the premise is that you must understand the language before you can understand how it really works, so I would rather spend time learning more about the language itself and apply the skills learned to other languages. Or on the library.
Building small modules
Some small units of code are nice and pleasing to programmers, because smaller units are easier to understand and harder to mess up, so it's important to limit writing long and complex code.
So build some small modules with purpose - as close to the requirement target as possible. They should be independent blocks that simply solve one aspect of the problem, but when combined they can solve many large, complex problems.
Simple module code like these will make it very easy to fix bugs. Because these individual blocks are easy to understand, you'll know their purpose at a glance. It's easier to test if the module is self-contained.
The less code the better
To paraphrase Biggie Smalls: "The more code, the more problems ".
Everyone likes code with less management. I guess everyone has had this experience. When reviewing the code of a functional module, if the code is a lot and messy, the first impression will definitely be bad. On the contrary, if the module code is concise and clear, you will be very happy. To put it more generally, the more code there is, the more difficult it is to manage: it will take longer to search the code base, it will also take longer to view the file navigation, and it will also become difficult to track the execution, etc.
Have you discovered that code review and the tools you use are largely used to reduce the amount of code. Those huge libraries and long codes seem to overflow people's brain buffers. I get frustrated when I'm tracing a long source code or performing a function that jumps over several source files. This is why I love editors that colorize syntax, and keeping consistent spacing helps me a lot.
In addition to preferring less code to manage, I also support developers trying to simplify their code as much as possible. Programmers are responsible for the code used by applications, not just the parts they write—even every line of code in those applications. This also means being responsible for bugs or security vulnerabilities that appear in these applications.
Would you use code you don't understand in your program? This doesn't mean that I never use other people's code - frankly, there are many good programmers in the world, but when applying other people's code, you have to understand the code because every line of code in the application is important. Never forget to think when coding. There should be more thinking behind writing the minimum code, so as not to cause unnecessary trouble to yourself.
Write simple, useful and readable code
Write code that is easy to understand, code less and think more, so that you can complete a function quickly and your productivity will increase.
Of course, I also want the code to be verifiable. And I've always believed that simple, modular code is easier to test.
Another characteristic that code should have is readability. Code should be concise and concise with clear semantics. When I write code, I think about how long it would take other programmers to understand it when they first see it. Or will I be able to figure it out myself in a month or two? As the well-known programming proverb: Any fool can write code that can be understood by machines, only good programmers can write code that humans can understand. The less time I spend trying to discover how they work, the more I get done.
But few people stick to these rules, and I'd be lying if I said they did. Sometimes I can be lazy, even due to time constraints, and I will write some complex, hard-to-understand code or use unreviewed libraries to implement a certain feature. Writing simple, clear code can be difficult in the short term - it requires more discipline and constant technical evaluation. Especially time-sensitive projects will be more difficult to implement.
But when you put the time and effort into it, you'll find that it pays off—not just for you, but for other team members as well.
From: More Code, More Problems
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
