171–180 of 360 posts
Earlier quoted context omitted.
Hi, there is a local run option with instructions here: https://github.com/github/super-linter/blob/master/docs/run-...
Have to install docker to run a linter... Nah, thanks.
Earlier quoted context omitted.
I can wholeheartedly recommend Black for Python, gofmt for Go, and terraform fmt for Terraform. What are some other great formatters out there?
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
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
Am I the only one that dislikes linting? Btw, you don't have to respond with the talking points I've heard all my life on why it's supposedly great, I've obviously heard them and think they're bogus. I just find it strange that I'm the only one.
Earlier quoted context omitted.
To me, because readability is the most important aspect of programming, and it needs to be done right.
But what do you get in that regard by not using black? Maybe in 1% of cases you’ll find a better way of formatting that everyone will also agree is better. That doesn’t seem worth very much at all to me, especially when by not using it you have to do a lot of manual work across the entire team now to get the 99% that is free with black.
Things like changing names to affect line breaks, inlining or outlining expressions etc.
Small things can turn 1 line into 8, and vice versa.
Great! 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…
In general, I tend not to care a whole lot about style, except to try and match whatever is pre-existing, as long as it’s vaguely readable. Otherwise, it’s basically whatever python-mode on emacs does, subject to a reasonable line length. Formatting nitpicks in code review bug me enough that I always just give in and do what they suggest.
Great! 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…
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…
Earlier quoted context omitted.
Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / ind…
This is basically solved by pinning the formatter to a specific version in your project's dependencies, and enforcing its use in continuous integration. Of course that doesn't help if you're setting up the formatter for the first time, or want to upgrade to a new version. Some tools like GitHub's diff do try to deemphasize whitespace but it's pretty limited.
1. Use a tracked directory for Git hooks: `git config --local core.hooksPath 'git-hooks'`.
2. Create format.bash and lint.bash.
2.1. Run `black` and `isort` in format.bash.
2.2. Run `flake8`, `mypy`, `black` and `isort` in lint.bash.
2.3. Run lint.bash in the pre-commit hook.
2.4. By default, lint/format only files which are different from origin/master to save time: `git diff --diff-filter=d --name-only -z origin/master "[asterisk].py"`.
3. In CI, run lint.bash with `--all` or some other keyword to verify formatting on every file: `git ls-files -z -- "[asterisk].py"`.
After more than a year with this setup I absolutely adore it.
Earlier quoted context omitted.
Have to install docker to run a linter... Nah, thanks.
Installing Docker is so easy, and it’s significantly easier than installing individual tools when we’re talking about shared tooling and local development. But hey, you do you!
Earlier quoted context omitted.
Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / ind…
Why don’t we just check ASTs in to git instead of text files ?
Earlier quoted context omitted.
Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / ind…
Why don’t we just check ASTs in to git instead of text files ?