331–340 of 360 posts
There seems to be a universal law of software systems that if small, self-contained subsystems exist - someone will glom them all together into an Uber-system, and vice versa. It’s inescapable.
— Dogbert, Build a Better Life by Stealing Office Supplies (Dogbert’s Big Book of Business), Scott Adams, 1991
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…
We spent a lot of time on making the code look like it at least came from the same company. And weeks of my life has been wasted trying to get people to agree on code formatting and coding style.
Fast forward a few years and we start using Go. I didn't agree with some of the formatting choices or code conventions. And pretty much everyone on the team had at least one thing that would grind their gears.
But we agreed that we'd use the gofmt tool to format the code. As everyone now does: by ensuring whatever IDE or editor we use pipes the code through that.
It took less than a week for everyone to adapt and I have hardly heard anyone complain since. There are still things I think could have been different, but for me, that's a very low price to pay for not needing to have these discussions.
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.
They use the excuse of the linter sometimes highlighting potential bugs to impose their preferred formatting style wholesale over everyone. And it's purely an exercise of power of one person over others -- the computer doesn't care about your style.
And it's not enough, some people will ask you to move sections of code around and start arguing about naming once they have no inconsistent white spaces to complain about -- that's how you know it's not the linter or formatter that they want, they want to control people.
Earlier 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…
Personally I vote to let people write code in the format they are most comfortable with and run the formatter as part of CI
I also believe that formatters should be "light-touch" and not have an opinion about every last thing. At that point I start thinking, "if you so smart, why don't you write the bloody code!"
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…
Earlier quoted context omitted.
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…
There are two kind of painting. You can paint a wall/a building, or you can paint Mona Lisa. This is the same for programming. Each dev have their own taste in term of code style and code formatting preferences. I was an early employee in a startup, and at some point I was able to tell who wrote a chunk of code just from the code style, it was fun :) but as company grown, and team got bigger, it got more "professiona…
One simple example is when you're parsing text and you have a long list of simple one-line if statements. I personally think it's wasteful and harder to read that block of code if you impose curly braces and new lines on that list of conditionals. This kind of formatting convention has been around for at least 40 years, and it makes the code more readable. I have yet to see an auto-formatter that doesn't turn that kind of code section into an unreadable mess.
Seems like this is the equivalent to GitLab's Code Quality CI template [1]? Which is supposedly built on Code Climate [2]. [1] https://docs.gitlab.com/ee/user/project/merge_requests/code_... [2] https://codeclimate.com/
Oh we use GitLab for work. Was wondering if there's an equivalent for that or similar.
We have also seen that SuperLinter can be run as part of a GitLab pipeline without too much hassle.
-James H Product Manager - Testing
Earlier quoted context omitted.
Oh we use GitLab for work. Was wondering if there's an equivalent for that or similar.
GitLab Product Manager here - The Codeclimate engine that out CodeQuality feature uses does support about half of the same languages as SuperLinter through plugins that can be added in the codeclimate.yml file. We are exploring how to support the missing languages and add output to the existing and future CodeQuality features. We have also seen that SuperLinter can be run as part of a GitLab pipeline without too much…
Seems like this is the equivalent to GitLab's Code Quality CI template [1]? Which is supposedly built on Code Climate [2]. [1] https://docs.gitlab.com/ee/user/project/merge_requests/code_... [2] https://codeclimate.com/
Just a poor experience all around.
GitHub's approach here seems much more sane.