-
-
Notifications
You must be signed in to change notification settings - Fork 551
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eslint #2446
Eslint #2446
Conversation
node must be on parent folder
This reverts commit 39658f7.
@ImprovedTube I move the test file out of tests folder as node.js package can only access file and child file only, if put in tests folder, it cannot test file from e.x. js&css folder |
e353e2b this is beautiful! It flagged real hard to spot on first glance error |
those are nice too
this https://github.com/SonarSource/eslint-plugin-sonarjs set of eslint plugins has some nice rules, for example
still cant find anything for flagging lack of space between condition and { |
current planning to add this: https://www.npmjs.com/package/eslint-plugin-compat |
I have tried no-same-line-conditional rule, it is not working for me, not flagging anything. I think what you want is the brace-style rule right, will be adding that in |
requires eslint-plugin-sonarjs
all those eslint rules not only make code more readable, but they already found few real errors, this is great 👍 |
whoa thats an ugly one Line 392 in cbd9a77
|
Yeah, fantastic job @dodieboy. |
oh, merged early Can we undo / adjust the last commit? - Precisely: Let's not add much white space automatically, where it loses format intended by an author (one-liners) (and semantic indentation, which can rather be replaced /enhanced by comments.) Example:
try {
chrome.runtime.sendMessage({action: 'play'})
} catch (error) {
console.log(error); setTimeout(function () {
try {
chrome.runtime.sendMessage({action: 'play'}, function (response) {
console.log(response)
} );
} catch { }
}, 321)
} ...isn't it still laborious to actually scan mostly empty surfaces? @dodieboy @raszpl /am i the only one still frustrated by this inefficiency? VS:try {chrome.runtime.sendMessage({action: 'play'})} // else log the error, then repeat & log the 2nd response too.
catch (error) {console.log(error); setTimeout(function () { try { chrome.runtime.sendMessage({action: 'play'}, function (response) { console.log(response) } ); } catch { } }, 321) } // Story: this single function-call ( Once code is well-predicted not to change, then format can be condensed. (Once syntax is verified, final, transactional.) Since any "density" might reduces under-challenge, increase efficiency. (And for who actually spots a long line, and also is "annoyed" by it, then this attention for this detail is more of a meaningful choice (Unlike long documents for everyone) (and likely developer who cares also has style / beautification in their IDE))
+ Generally on Indentation & braces:Humans actually need not to see (nor input) both. (One is enough.)
|
white space is good for readability
bad format leading to errors, brace-style rule will guard against horrible crimes like this:
I cant see on first glance whats going on. This is what brace-style rule will let us spot and fix.
This invocation will allow one liners in braces: ============================================================
cant really fix bad formatting with comments :)
its perfectly readable :] Seriously, what do you find offensive in this piece of code? other than 'repeating identical behavior and expecting a different result.' aka definition of insanity :]
no, empty surface is what lets you read if faster because white space also conveys meaning. What is not there is just as important as what is there :) In a tight jumbled up version one has to actually read everything, in properly formatted version you can see by the indentation what is what without reading most of it.
How long and how much have you programmed? Appreciation for code readability comes with experience and age.
its information, lack of appreciation for it leads to things like this b24ede7 :(
the purpose is not writing bugs :) There are tons of programmers, mainly C ones (hehe), with hubris believing they are above all that and dont need any help writing error free code. If that was the case we wouldnt need MISRA, Ada, etc.
seriously cant know what this "code vomit" does without carefully reading it and painstakingly tracing and parsing in my brain all code blocks There are two try and catch all in one group, which one does what, and why? With proper indentation those things dont require any thinking because blocks are aligned according to their roles and order.
If that was really the case we wouldnt be finding and fixing errors after ESLint flagged them in this 3?5? year old project? :)
leads directly to this b24ede7 |
PS: crowdin.yml is spamming errors
|
@ImprovedTube why crowdin.yml is in the workflow folder? |
Oh sorry dodieboy , I assumed it was somehow linked to elsing install |
😀 hi @raszpl So this needn't be a difference between programming languages in the first place, let alone a global convention inflating source code files. And if it could just be a simple style declaration, for how one views code personally at home, that will be the fix. While writing code I enjoy the fingers recovering from using space tab & enter. But if we enter some white space for semantic reason, this needn't be lost next time somebody clicks 're-format' in some way. |
Updated eslint rule
Move the test file out from tests folder
Fixed node.js workflow error
Fixed more code indent