BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] php dev's code with warnings and notices
- Subject: [Discuss] php dev's code with warnings and notices
- From: richb at pioneer.ci.net (Rich Braun)
- Date: Sun, 27 Jul 2014 11:26:29 -0700
- In-reply-to: <mailman.82751.1406467425.15487.discuss@blu.org>
- References: <mailman.82751.1406467425.15487.discuss@blu.org>
Eric Chadbourne asked: > The code they have submitted works, > but it has a bunch of warnings and notices in the logs. I personally > think this is sloppy coding. My question is, how strong a stand should > I take on this issue? I have the senior role but I am also the "new > guy". I've recruited a team of Ruby coders over the past year, and despite the "green-fields" status of the project (brand-new code-base) we found over 6000 exceptions in the code the first time we ran a tool called Rubocop to look for syntax sloppiness. We got one intern for the summer, a strong-willed Stanford sophomore, so I put him on the task of code cleanup. A couple days later, he pushed back with this very coherent argument: if you have me touch 150+ files but don't have full unit-test coverage, aren't you asking for more trouble than this cleanup is worth? My suggested response was that we gate the build pipeline with a Rubocop check (along with other static-analysis tools) for all newly-modified files, ignoring problems with the older files. Ultimately, we wound up just in the past few days opting to accept all of the intern's cleanup; we'll fix whatever logic problems crop up. But the team's still not fully convinced we've made the right choices. My suggestion for you, Eric, is to ignore the problem unless you have management buy-in (and a reasonable level of team consensus) to do the following: * Implement a unit-test code coverage tool that reports all lines that aren't covered by unit tests, if you don't have that in place already, and run it at least daily if not every build; * Get the test coverage well above 50%; * Block all code check-ins that worsen the problem (i.e. implement a static-analysis gate). Gating code check-in deserves its own post; there are git hooks, Jenkins static analysis scripts, etc; team members always have strong opinions about when to run what tools against which files during the development process. And no two people seem to agree on the integrated development environment (IDE) choice. -rich
- Follow-Ups:
- [Discuss] php dev's code with warnings and notices
- From: peabo at peabo.com (Peter (peabo) Olson)
- [Discuss] php dev's code with warnings and notices
- Prev by Date: [Discuss] Verizon getting out of being regulated
- Next by Date: [Discuss] php dev's code with warnings and notices
- Previous by thread: [Discuss] php dev's code with warnings and notices
- Next by thread: [Discuss] php dev's code with warnings and notices
- Index(es):