I believe this might have been discussed before, but I'm seeing a lot of inconsistent styling with the snippets scrolling past each one so far. I feel like keeping them normalized with Prettier would help alleviate this. I understand that Prettier creates extra lines to "prettify" the code, which goes against the snippet-y shortness aspect in some cases, but I kinda prefer that anyway.
etc.
Original
const intersection = (a, b) => { const s = new Set(b); return a.filter(x => s.has(x)); };
Prettier
const intersection = (a, b) => {
const s = new Set(b);
return a.filter(x => s.has(x));
};
Original
const arrayLcm = arr =>{
const gcd = (x, y) => !y ? x : gcd(y, x % y);
const lcm = (x, y) => (x*y)/gcd(x, y);
return arr.reduce((a,b) => lcm(a,b));
}
Prettier
const arrayLcm = arr => {
const gcd = (x, y) => (!y ? x : gcd(y, x % y));
const lcm = (x, y) => x * y / gcd(x, y);
return arr.reduce((a, b) => lcm(a, b));
};
Original
const collectInto = fn => ( ...args ) => fn( args );
Prettier
const collectInto = fn => (...args) => fn(args);
Our linter was supposed to handle all of that, but it seems to have a few problems as of now. We have adopted semistandard for our styling, but we need to finally figure out why it is inconsistent and deal with that.
This linter from Sindre Sorhus is very cool https://github.com/sindresorhus/xo. It has an autocorrect obvious mistakes feature.
xo + ava + es6 solves most of the flaws of JavaScript not having a compiler IMO.
I agree with @Chalarangelo. We already set up linter, it is supposed to do that. If that doesn't work we should be more strict when new snippets are PR-ed. That is not great solution, but as you said:
we need to finally figure out why it is inconsistent and deal with that
Some of those are probably mine. I use an auto formatted in VScode then move it over to the snippet. I have some rules to avoid obvious problems with reading like the parenthesis hell situations which makes it easier to count parenthesis, and putting in leading spaces because it makes it easier for me to visually grep, but they're mostly personal preference. I thought that linter would take care of that, but if it doesn't also auto correct spacing...
All of this comes out of the fact that I do a lot of composition:
Promise.resolve([1,2,3]).then(console.log)
Promise.resolve( [1,2,3] ).then( console.log )
Promise.resolve( [1, 2, 3] ).then( console.log )
Promise.resolve( [ 1, 2, 3 ] ).then( console.log )
Now imagine about 20 lines of that in any of those styles. Finding a good balance makes it a lot easier to read in extremely dense code, especially if you have build tools that strips it and uglify it. However for snippets it's often unneeded and makes it a little clunky. My bad. If we want to use a stylizer I'm all for that. I might just go back to default formatting rules for VSCode for this projects space since they are much closer to the project
@skatcat31 I also use VS Code, so here is my advice for you: Set up ESLint for yourself with Airbnb style guide, it will force you to write more readable code + your snippets would be exactly the way our style guide wants them to be.
TL;DR: We are using semistandard, anyone who submits PRs, please take 5 minutes to read through it. The linter should work and fix those problems, but it doesn't always. PRs fixing said formatting and styling problems are always welcome and mergeable immediately. We have no intention of changing style as of right now, but we might in the future.
So linter-script.js is what formats/lints the code?
When I run the first example in the OP through this:
semistandard snippet.js --fix
it doesn't format it at all.
It does format depending on the code snippet, but it varies, and it's not extensive like Prettier...
Promise.resolve( [ 1, 2, 3 ] ).then( console.log )
Promise.resolve([ 1, 2, 3 ]).then(console.log);
As you can see, there are still spaces around the square brackets of the array. I guess it doesn't format/fix those types of inconsistencies thoroughly like Prettier does. Therefore I recommend adding Prettier as the second step?
However the arrayLcm one does get fixed mostly, so not sure why that one doesn't work.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for any follow-up tasks.
Most helpful comment
TL;DR: We are using semistandard, anyone who submits PRs, please take 5 minutes to read through it. The linter should work and fix those problems, but it doesn't always. PRs fixing said formatting and styling problems are always welcome and mergeable immediately. We have no intention of changing style as of right now, but we might in the future.