Official Style Guide for Vue-specific code
style guide for Vue.js
An official style guide (beta) for Vue-specific code has been released. Chris Fritz announced the style guide on Twitter.
You can find it under the Learn list on the homepage of vuejs.org.
This guide comes before version 2.5 of Vue, planned to be released in this October. The Beta version of the guide can help developers avoid common errors and pitfalls by dividing rules into four categories. This is meant to be the best reference when building your projects but the team has made some comments about this guide:
Also, Chris Fritz said in one reply: Just keep in mind it's a living document and in beta, so it's likely to go through some changes in the next month especially.
The rules fall into four categories A, B, C, & D, from higher priority to lowest.
Priority A: Essential
Priority B: Strongly Recommended
These rules have been found to improve readability and/or developer experience in most projects. Your code will still run if you violate them, but violations should be rare and well-justified.
Priority C: Recommended
Where multiple, equally good options exist, an arbitrary choice can be made to ensure consistency. In these rules, we describe each acceptable option and suggest a default choice. That means you can feel free to make a different choice in your own codebase, as long as you’re consistent and have a good reason. Please do have a good reason though! By adapting to the community standard, you will: train your brain to more easily parse most of the community code you encounter be able to copy and paste most community code examples without modification often find new hires are already accustomed to your preferred coding style, at least in regards to Vue
Priority D: Use with Caution
Some features of Vue exist to accommodate rare edge cases or smoother migrations from a legacy code base. When overused, however, they can make your code more difficult to maintain or even become a source of bugs. These rules shine a light on potentially risky features, describing when and why they should be avoided.
Soon, we’ll also provide tips for enforcement. Sometimes you’ll simply have to be disciplined, but wherever possible, we’ll try to show you how to use ESLint and other automated processes to make enforcement simpler.
Visit the page and share your feedback with the team!