It might be useful to re-format a completely messed up piece of code coming from the external world, but on the team I always prefer styleguides in the mood of "recommended, never enforced", which "prettier" is exact opposite of. It seems so misaligned with the original purpose of writing the code (which comments are a part of). And using comments to hold your auto-formatter back always baffles me. Example with the matrix shows pretty well, why exceptions are always possible, no matter how detailed your styleguide is. People here seem to approve it, but I feel unsure. rather than arguing over where we should and shouldn't have spaces in our code.Įdit: my TL DR answer would be that it's a virtually zero configuration way to guarantee stylistic consistency. I am optimistic that the community will keep on adopting it, helping make our code more readable and allowing us to focus on actually building libraries, tools, applications, etc. I have always loved that Python has an "official" style guide ( ), and gofmt ( ) is one of the reasons I want to try out Go, so Prettier is a great development in my opinion. With those linters, you also need to decide how to configure the rules (though picking a preset can make that easier). They check for programming errors as well, not just stylistic issues. It also isn't doing exactly the same things as linters. Prettier will make almost all that bikeshedding unnecessary.Įven with ESLint having autofix capabilities, Prettier seems far more comprehensive in that regard. In most cases, just picking a consistent standard is far more important than whatever the choice happens to be. I've personally experienced how much time can be wasted bikeshedding over stylistic issues. Speaking for myself, I've been waiting for 1.0 before using it, but I've been very excited for this project since its announcement. Congrats to all of the contributors on the 1.0! It's been great to see this come from the community and I look forward to seeing where the community takes it. PR reviews focused on what the code is doing vs painful style nits is huge. Removing barriers to contributing to open source projects is huge. Personally, I support the Prettier mission 100%. That's largely anecdotal evidence from my time at Airbnb and of course your mileage my vary. I will say an added benefit of including a style guide in a project for large teams that may get lost jumping straight into prettier, has been helping our engineers become stronger javascript programmers in the process of learning our style guide. As always, please do what works best for your team or project. If your project treats JSX and JS the same then yes, we've certainly seen folks do this. We diverge from the community a bit in the sense that we treat JSX as not JS and we aim to be consistent about that. Would it be more consistent to treat strings the same everywhere? For some projects sure. We use eslint to enforce and maintain the consistency. The important part for us is consistency at Airbnb. One of the Airbnb style guide authors here. Rails, for example, famously touts that any engineer can walk onto another Rails project and have a reasonable suspicion of where to find a particular piece of code. How often do two node projects created by different engineering teams end up with the same folder/file structure? There's nearly no strong community convention, unlike many other languages/frameworks. I'm hoping to see similar efforts on project file/folder structure at some point. Why the difference? Why not stick with double quotes everywhere, as they are required in JSX blocks? Answer: legacy code at Airbnb For example, the Airbnb JS style guide recommends single quotes in JS, but double quotes for JSX properties. What standards do exist are frequently arbitrary, or enforced by legacy code at random companies. Prettier goes such a long way to enforcing standards on a language and ecosystem which otherwise has none or few.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |