You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the discussion in #11, I came to the conclusion that we should introduce a list of accepted custom styles. With tools like prettier and eslint --fix, I think it's less important to have a unified coding style across all Peerigon projects. There are a lot of rules where it doesn't really matter what we choose, like:
With these rules, it is more important that they are applied consistently throughout the project. Without prettier and autofixable eslint rules, it would be tedious to remember all the styles and to switch between projects. But with autofixing you can just write it using your style and let the tools do the rest.
There are now two questions that come into my mind:
If we allow custom styles, what's the point in having a peerigon style in the first place?
I still think that it's important to have a set of rules where we agreed that they are useful and important. But there are also a lot of rules, where it doesn't really matter what we choose: it's the consistency that matters. Personally, I prefer very strict and autofixable rules because then the code looks like it has been written by one person. But I don't necessarily insist on certain rules like "double quotes" or "spaces".
Why can't we just override the rules in our project?
I don't think that we should override rules inside our projects. If we do that a lot, using a central coding style doesn't make sense. A lot of rules have been chosen carefully and are based on a lot of experience. If we just override rules because we simply don't like them, all the experience and careful consideration is just thrown away. The difference in this approach is that we define a set of accepted deviations from the standard rules, where we agreed that it is not really important what to choose.
So, how would these list of accepted custom styles look like from the user's perspective? I'd create one file for each rule, so that the .eslintrc would look like:
Based on the discussion in #11, I came to the conclusion that we should introduce a list of accepted custom styles. With tools like
prettier
andeslint --fix
, I think it's less important to have a unified coding style across all Peerigon projects. There are a lot of rules where it doesn't really matter what we choose, like:With these rules, it is more important that they are applied consistently throughout the project. Without prettier and autofixable eslint rules, it would be tedious to remember all the styles and to switch between projects. But with autofixing you can just write it using your style and let the tools do the rest.
There are now two questions that come into my mind:
If we allow custom styles, what's the point in having a peerigon style in the first place?
I still think that it's important to have a set of rules where we agreed that they are useful and important. But there are also a lot of rules, where it doesn't really matter what we choose: it's the consistency that matters. Personally, I prefer very strict and autofixable rules because then the code looks like it has been written by one person. But I don't necessarily insist on certain rules like "double quotes" or "spaces".
Why can't we just override the rules in our project?
I don't think that we should override rules inside our projects. If we do that a lot, using a central coding style doesn't make sense. A lot of rules have been chosen carefully and are based on a lot of experience. If we just override rules because we simply don't like them, all the experience and careful consideration is just thrown away. The difference in this approach is that we define a set of accepted deviations from the standard rules, where we agreed that it is not really important what to choose.
So, how would these list of accepted custom styles look like from the user's perspective? I'd create one file for each rule, so that the
.eslintrc
would look like:What do you think?
The text was updated successfully, but these errors were encountered: