Reading through all these comments I see a lot of people saying "it stops the debate about style!"
It seems like people are having more of an issue with bike shedding than actual code formatting.
GitHub Super Linter: one linter to rule them all
201–210 of 360 posts
Re: GitHub Super Linter: one linter to rule them all
#202Obligatory XKCD comic: https://xkcd.com/927/
Re: GitHub Super Linter: one linter to rule them all
#203I'd like to find a formatter that aligns opening and closing braces and parentheses vertically, if they span more than one line. Is there such a formatter?
Re: GitHub Super Linter: one linter to rule them all
#204Am 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.
I'm strongly against over-bearing autoformatters.
In my experience a little hand crafting tweaks to formatting go a long way to increasing understandability.
It feels like a lot of people are having issues with bikeshedding and they're using enforced autoformatters to impose their will and stifle debate they may not like.
Not arguing about style is nice, but having to resort to this brutalist architecture style of code formatting doesn't seem great to me. "Its just holding people, who CARES what the building looks like!"
Also thing like line-length limits. I'm with Linus on this one, enforce line-length limits causes a lot of problems, like breaking context in greps. And an autoformatter that breaks at a certain number of characters is never going to be able to understand the context to break it intelligently.
Are people using editors that don't display long lines wrapping properly? Do people think everybody uses the same resolution, the same window size, the same columns per terminal, etc?
Re: GitHub Super Linter: one linter to rule them all
#205Earlier quoted context omitted.
This is just me btw, don't take offense: Because some things are better expressed in different rules. That's why some syntax is optional in the first place, that's the reason it was made that way. The flexibility is a very intentional feature. It wasn't an accident. Maybe you want multiple spaces to vertically align code in a complex set of logic. Maybe you want to express things on multiple lines to break them up. M…
I will agree with you that shitty linters are shitty. > Maybe you want multiple spaces to vertically align code in a complex set of logic. Maybe you want to express things on multiple lines to break them up. Maybe you have deep nesting so you want to go from 4 spaces to 2. Maybe you want no braces in a single line if statement except in certain cases. This could go for pages. Poof! All gone. You can't do any of it an…
> If those checks are present I would disable them.
The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore.
So now we just get to argue about what rules we can enable/disable?
Even though it's perfectly legal to disable linting for lines or files, most of the time when I do it, it's flagged by someone in review, and there's some discussion and I'm forced to rewrite and remove my disable and go back to whatever the linter was forcing. "These rules are there for a reason, and were put together by people with more experience and smarter than us - we shouldn't go disabling things whenever we want just because we don't like them or think we know better". (amalgamation of multiple comments from people stopping me disabling lint checks in specific situations).
This doesn't happen every time, but enough that the occasional 'disable' isn't something I can just do without worrying it will end in multiple hour discussions. Which is probably what people want - unquestioning conformity to "the one true way".
Re: GitHub Super Linter: one linter to rule them all
#206Earlier quoted context omitted.
It hasn't been my experience. I have had to deal with linters probably about 15,000 or so hours of my work life (luckily that's only about a third). It's been probably between 99.4% and 99.8% just acrobatic dog tricks to satisfy the linter. It's not like I'm some grumpy malcontent that hasn't given it a go. If you want to use it go ahead, I just thought I'd be standing in a larger crowd
Could it be that the problem with the linters you've experienced was that they were just configured far too strictly about things that don't matter too much, rather than linting itself being the problem? I've got my linters set up pretty loosely, but the things that are enabled have definitely helped me detect bugs earlier and quicker, and I really don't see how anyone could be against that.
well sure. There aren't bad tools just bad practitioners, sure. Certain tools give more affordance to certain use cases and maybe that's the issue.
For instance something where I am the culprit would be in PHP. I like PHP. I think it's a convenient and powerful language. Someone could take my linter arguments and weaponize them against PHP because it's too easy to do terrible things with it. Then I'd be the one on the other side of the argument all of a sudden, standing in defence of this easy to use language with handy powerful abstractions that can trash a system in a few keystrokes.
I think the difference is when we can come to an agreement that say, PHP is a very powerful tool in competent hands and a very dangerous tool for the foolish.
Going back to the topic at hand, I think the foolish side of linting is the dominant application I see in the wild. I used to use a barrage of proto-linting static analysis tools in my CVS scripts during the wild C days because pointer logic and memory management was notoriously tricky and gcc 2.x was notoriously forgiving. These tools could save days of debugging, really, yes, days.
If we can do that for say python it'd be great. Something saying "Oh I see you are doing a list[1:] in a tight loop, have you thought about collections.dequeue? it may be a better option" - those things are things I do actually forget about and would find helpful.
It'd have to be voluntary though. Prod me a bit but then let me dig my own grave if it's a mistake. That's what the power of computing is also about.
Re: GitHub Super Linter: one linter to rule them all
#207Is anyone else uncomfortable with Github/MS owning more and more of your tool chain? Maybe my lock-in radar is faulty, but the more this happens, the more scared I get.
I guess you've never worked in a .NET shop before? Or the days when everyone just developed on Visual Studio on Windows, before Macbooks for developers was a thing?
Yes I’ve worked in MS shops, even written Win32 code. I learned a monolithic dev ecosystem was what I personally did not want. So that pendulum swung more towards OSS...
Re: GitHub Super Linter: one linter to rule them all
#208Earlier 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…
Normally I agree with treating code as a means to an end rather than an end to itself but I take a certain enjoyment in crafting in some way aesthetically pleasing code as well. I even find that if the code is "ugly" that there frequently might be a more eloquent and objectively better way of doing things. And a little time hand formatting I think is worth it if you're maximizing understandability and readability. No…
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.
Re: GitHub Super Linter: one linter to rule them all
#209Great! 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…
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.
Re: GitHub Super Linter: one linter to rule them all
#210I like the way it improves the quality of deploys. Actually different approach but same aim is hidden behind Assistant extension to Visual Studio Code. I think both solutions are complementary to improve quality of team work. If you want to check Assistant out version 0.9.0 was just released two days ago: https://marketplace.visualstudio.com/items?itemName=tomasz-s...
It would be nice if you said that it's your own extension...
My name is Tomasz Smykowski.
Assistant is my design.
And I am proud of it!