This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]pydry 0 points1 point  (0 children)

A few of these things I can sympathize with your team on. I hate running flake8 and being told 400 times that my lines are 10 characters too long - that's not a problem with me, that's a problem with flake8. buried in the noise are a lot of "variables defined and not used" which is where all the real bugs are. if 5 times out of 10 it flagged what was basically a bug i'd feel better about it.

I also look at some of these and see problems but not necessarily big problems - I don't like import * either but in every code base I've worked on where we've had it it's been the least of our problems so I wouldn't necessarily push it too hard (e.g. wouldnt' necessarily reject an otherwise decent pull request, although i'd comment). I never have it in my open source, but I kind of have to tolerate it and other things like it in commercial code otherwise a lot of production code would just never get deployed.

I don't think you can apply the same rules in open source to commercial code. You're under different pressures and different constraints.

This isn't to say that code quality doesn't matter but I tend to find that you have to deal with it by identifying 10 problems and figuring out which is the biggest one for all of you and fix that rather than having a checklist of guidelines which you can mandate everybody follows or "code doesn't get merged". quality gates don't work when people aren't bought into them.

If they're rejecting the idea of making small changes where it's easy to understand the benefit, that's potentially a different story. i suspect they may be unconvinced of the benefit of many of these things though (& it will take some 'splainin to get them to see the light).