Can someone recommend a Java alternative to ESLint for JS eco-system?
Used `checkstyle` 4 years ago to improve the quality of code. Has neat XML based rules and good IDE support.
See if it fits your use-case.
GitHub Super Linter: one linter to rule them all
311–320 of 360 posts
Re: GitHub Super Linter: one linter to rule them all
#312Earlier quoted context omitted.
GitHub Codespaces was announced at Satellite and it's basically what you say - a way for developers to skip the "setting up" step (often the most annoying step and single biggest blocker for OSS contributions) in a new repo. https://github.com/features/codespaces Disclaimer, I helped make these :)
Interesting. Yes this is definitely in the direction I was thinking. I'd also say Repl.it is very similar too. Maybe they'll be acquired.
> I'd also say Repl.it is very similar too.
Indeed. It's interesting that GitHub Classroom uses Repl.it (and another MS web IDE) rather than Github Codespaces:
https://github.blog/2020-05-26-code-in-the-browser-with-gith...
https://classroom.github.com/help/online-ide-integrations
Seems like a friendly ecosystem for the moment.
Re: GitHub Super Linter: one linter to rule them all
#313Earlier quoted context omitted.
Not to mention it dirties up version control. It's a lot easier to tell which _significant_ things changed from the last commit when you're scanning a diff and no formatting changes are highlighted.
Ive seen heaps of autoformatters dirty up version control. Mostly when theyre fussing about new lines. I kind of wish autoformatters would just ignore new lines and focus on indentation alone. It would certainly cut down on the over zealous rules. I also think formatting should be separate from linting but because they both require a parser people seem to think theyre the same thing.
My workaround is to run the formatted in the whole codebase as a separate PR, make the commit with a separate user that’s none of my colleagues (like “Prettier ”) and add that commit’s hash to a file in the repo. I then configure git to use that file for ignoring changes in git blame.
Now the code is formatted and additions won’t trigger reformatting the line or the file.
Re: GitHub Super Linter: one linter to rule them all
#314Earlier quoted context omitted.
The 88 character limit is just a best effort thing anyway. I find the double-quote coercion more disruptive.
I started programming in the 80s, so I'm used to double-quoting anyway. Apostrophes occur so often in English that it makes it easier to type strings like "I'm a dog". With single quoting you have to go 'I\'m a dog'. If I hit double quotes in a string, I just triple-quote. """He said "hah" sarcastically""". I know Guido (van Rossum) prefers single quotes -- I'm not sure why exactly -- so it's become a default Python…
Unless I mean straight quotes, I type curly quotes as a matter of course. Love my Compose key. :)
Re: GitHub Super Linter: one linter to rule them all
#315Earlier quoted context omitted.
I wish there was good C# one (and ideally a standard one like go). When switching between typescript with prettier and C# the first thing I notice is the lack of autoformating. edit: seems https://github.com/dotnet/format is the closest thing
I wish their was a standard c# formatter too. dotnet-format doesn't support wrapping long lines which is one of the more important features in my opinion. Resharper has a free command line tool that supports wrapping long lines. https://www.jetbrains.com/help/resharper/CleanupCode.html I made a wrapper for it to try and make it easier to use. https://github.com/sethreno/ReGitLint#regitlint
Thanks I will check it out
Re: GitHub Super Linter: one linter to rule them all
#316Earlier quoted context omitted.
Usually when introducing such a tool you do 1 commit that reformat the whole codebase to the new style and then automatically enforce it.
And in those large reformat commits, add a file like `.git-ignore-revs-file` that is checked in, so you can configure git to ignore that revision and pretend it never existed: [blame] ignoreRevsFile = ".git-ignore-revs-file" markIgnoredLines markUnblamableLines
That's an incredibly useful trick to know
Re: GitHub Super Linter: one linter to rule them all
#317Earlier quoted context omitted.
Consistent style is more important than each block of code being perfectly pretty. You can still argue aesthetics, but they need to be applied across the entire codebase. Never having to bother someone because their PR doesn't meet the formatting guidelines is well worth it.
> Consistent style is more important than each block of code being perfectly pretty "Pretty", yes, but we're literally talking about using language to communicate. Consistency taken to extremes is harmful to communication. I don't understand the worship that people have for consistency. STUPID inconsistencies are bad, yes, and yes, there are certainly arguments that about subjective matters that are a waste of time.…
I’d agree that 100% consistency is harmful to communication, but the primary communication happening in programming is with a computer. Even when it comes to other developers looking at your code, their internal process is “let me simulate what the computer understands”.
Unless you are enforcing weird autoformat choices, everything should look pretty enough.
Re: GitHub Super Linter: one linter to rule them all
#318Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…
gofmt's idiotic handling of maps and forcing them to align entries was enough to put me off the entire idea of autoformatters.
Enforcing a code style where adding a single byte can result in an unlimited-number-of-lines block in a diff is pure idiocy.
It's bad enough having to review someone's changes when they're polluted with this garbage, but it also makes merges fail more often and pollutes `git blame`.
The idea that people will put up with this crap because they can't just unclench about a few spaces here and there I will never understand.
"But it minimizes diffs because it stops people committing simple spacing changes" - people shouldn't be adding those hunks to their commits in the first place and such changes need to be pulled out in review. This will also get people out of the habit of just blindly doing a `git add`.
edit: I'm certain that if slightly non-uniform formatting really sets off your OCD then this should be solvable to some degree at the editor level, but please keep your obsessions out of my repository. In return I'll keep mine out of yours.
Re: GitHub Super Linter: one linter to rule them all
#319Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…
IMHO there should be a distinction between code serialisation (the bytes on-disk, in version control) and code formatting for display/editing.
The serialisation should be normalised automatically, preferably in a way that minimises line-based diffs.
The way code is formatted for display should be distinct, and can usually be more of a personal preference. Most people seem to be happy for their editor to use syntax highlighting to make things more readable, but not much else. Indentation, line length, aligning sub-expressions, etc. can also help readability, but showing those things differently from the bytes on disk is usually avoided.
Perhaps this is due to a conflation of meaning for certain bytes. For example, \n can mean "token separator" to the language, "long line splitter" or "intent separator" to the developer, "unit of comparison separator" to version control, etc.
Re: GitHub Super Linter: one linter to rule them all
#320Earlier quoted context omitted.
One of the hills I am willing to die on is auto-formatting. Code formatting is easily automated to an acceptable level, and people's personal preferences are subjective. I like to solve interesting problems, and concentrate on crafting high quality software. Manual code formatting contributes to neither of these disciplines. Code formatting is BORING robot work, not human work. Total pointless drudgery. Toiling away…
Not to mention it dirties up version control. It's a lot easier to tell which _significant_ things changed from the last commit when you're scanning a diff and no formatting changes are highlighted.
We've found https://git-scm.com/docs/git-blame#Documentation/git-blame.t... very useful in these cases. When Prettier changes significantly, we run across the whole codebase & add the commit to an ignore file.