preface
The exact title of this article should be: “formatting code using ESlint and Prettier in VSCode”. The author is a little more than two years into the line of newbie, some knowledge point understanding and the use of the tool 🔧 has been in the shallow level, do not want to be too lazy to go behind the hidden knowledge tree. But real experience tells me that all this is wrong. Steal a small lazy, or can not steal the future of laziness. In other words, it’s easier to internalize knowledge without having to go through extra experiences to remember it. Because it’s part of you, it just comes naturally to you.
For example, before I wrote this ARTICLE, I couldn’t remember how to spell “plug-in Prettier” and thought it was pretty darn weird. But, just now, I realized that this word is derived from pretty. Pretty means prettier, the derivative of prettier becomes personified, someone who makes others prettier. This other person is referring to the code we wrote. And in the English context, it is really intentional. This way, the word is easy to remember.
Based on this, I also hope to be able to sort out the process of plug-in code formatting, in order to really use tools to improve our development efficiency.
What is code style
This question is the most basic and the most important. Only by understanding this question can the following questions make sense. The code style can be compared to the writing style, only the writing style is more colorful. For example, the aesthetician Zhu Guangqian’s writing is simple and direct, but it is easy to make people empathize. When I first read his twelve Letters to A Young Man two years ago, it gave me much thought. That kind of teacher’s earnest teaching feeling, still let me forget. Similar to the English environment of the writer Hemingway, is tough, people send the title – The American tough guy. This is a style of writing. The code style is more specific, such as no semicolons at the end of sentences, no Spaces for functions, and the format of function comments. These bits and pieces make up the style of the code. Style is not good or bad, only suitable. Its purpose is to make code easier to understand, given that it’s written for people, with the added bonus of running on a machine.
Why keep the code style uniform
The answer is to ensure a good, continuous reading experience in collaborative development, reduce code ambiguity, and allow subsequent developers to continue development efficiently and quickly. In other words, read other people’s essays. Clear writing, clean and tidy articles, looking at people feel comfortable, more willing to continue to read.
In what way do you maintain a unified style
To maintain a uniform code style, you need a standard code style specification that needs to be negotiated. So once you have a standard, who’s going to verify that it’s being implemented? How do you enforce standards?
To think about these two issues anthropomorphically, we need a “standards enforcement committee” to enforce code style standards. In the computer world, the committee’s role is played by a separate program — ESlint. We prefer to call this program a plug-in.
Remember that when initializing a new Vue project, there are some default plug-in installation prompts, one of which is ESlint. If you choose to install the plugin, when you run your project NPM run Dev, the IDE will run the ESlint plugin to check that your code complies with the ESlint specification. If not, a series of warnings are reported to the console. This also shows that your project has basic code style verification capabilities.
The double face of ESlint
Euler Euler Euler, come out, my double!
We usually talk about using Eslint to normalize code, but here Eslint has two faces. Without distinguishing between them, some descriptions can easily confuse our brains. First and foremost is the ESlint plug-in installed during project initialization. It can also be installed via NPM I installation dependencies after a new project is created. Its purpose is to check that the project code complies with established style standards when running or packaging the project. This also means two things:
- It requires a description file of code style standards.
- It only knows if the code meets the style criteria when the project is finally run.
The solution to the first problem is the.eslintrc.js file at the root of the project, which specifies the specifics of the code style standard. The Eslint plugin will read this file to compare the project code style, and if it doesn’t, it will issue warnings or other alerts. The solution to the second problem required IDE participation, and this was the birth of the second face of ESLint, the VSCode plug-in mode.
VSCode as Microsoft’s main integration development tool, free is one of its characteristics, another is the plug-in model. The common ESlint plugin solves the second problem. When you install the ESlint plugin, it verifies your code in real time against your.eslintrc.js. If the specification is not met, a red wavy line will appear at the corresponding location. It moves from passive validation at run time to active validation at code time, preventing irregularities in the early stages.
Prettier and ESlint
Their relationship is interdependent, ESlint detects errors, Prettier corrects. Error detection Read the configured.eslintrc.js file to check whether the format of the code conforms to the configuration, and report an error/warning if the code does not comply. But it doesn’t know how to fix what’s wrong. For example, if you configure 4 Spaces at the beginning of each line of code, ESlint will check that you don’t meet the specification if you only indent 2 Spaces. However, it will not correct your incorrect formatting. That’s not its job description.
This requires an error-correcting tool. The tool requires formatting code, which is what Prettier does — making code Prettier.
Prettier is usually run automatically when a file is saved to format the code where the file is being modified in order to solve the problem early. Because error detection and error correction tools are not the same thing, there will inevitably be areas of conflict. So there’s the news of resolving a conflict between Prettier and ESLint.
Refer to the article
www.cnblogs.com/mspeer/p/12…