On another tangent, I love seeing what music the authors were listening to while coding. Some might argue that it has no place in a README but... it's a nice touch.
On another tangent, I love seeing what music the authors were listening to while coding. Some might argue that it has no place in a README but... it's a nice touch.
Of course, I do all my serious coding while listening to the fine music of MASTER BOOT RECORD.
As if other people writing and sharing code freely is a huge problem.
I think it is different when a project is part of a commercial offering, or funded by something you participate in.
People love shitting on closed source projects too, but the circle of people you can reasonably do that in is fairly limited.
Everyone can see this code, so you can shout it to the world.
Does your CI read IDE settings or language specific settings? If you're depending on IDE specific settings in your pipeline, your entire pipeline is brittle.
So, no "sufficiently complex project" should need any IDE specific config in the project repo.
Using your logic, any IDE with a settings dialog is crap…
See how ridiculous this sounds? It sounds more so like you hate VSCode
You are reading things into my comment that aren't there. Maybe you should reread it. Especially the part where I talk about the separation of project specific configs and general IDE configs. Or how your CI should be able to pick these things up.
> It sounds more so like you hate VSCode
What else are you seeing down there in the tea leaves? Did I say anything about VSCode?
Golang certainly has no such file, so you’d have to read from the main package and understand every CLI framework out there to parse out the sub commands to build your launch configuration. Sounds real easy right?
Now if we’re talking about nodejs, where the package.json can hold your run configurations within the script section, then ok. But we’re talking about golang.
I don't think there are any red flags there IMHO.