Re^2: CPAN's perltidy to the rescue! (not for 'standards')

[ruzam]

My last big corporate gig involving COBOL (many years ago now) jumped on board the 'standard code' bandwagon. The company paid dearly for a tool that defined every single aspect of COBOL code. Unlike perltidy, however, this tool didn't reformat code, it only scanned it, then spit out a long list of deviations followed by a grade. Many, many meetings were held to discuss 'what' should be considered standard code (which varied from department to department), followed by more meetings about how the standard was going to be enforced within the company, and even more meetings about how to deal with legacy code (which not surprisingly, was eventually excluded from the standards). Standards committees created and standards reviewers positions were created to ensure that all work met minimum standards. Code reviews stopped being about whether the code actually worked the way it was supposed to, and instead became reviews about how to fix it so that it passed the minimum standard grade. After several years of this the overhead fell in on itself and the 'standards' grading system was scrapped in favour of common sense code reviews. If there had been a 'COBOLTIDY' back in the day instead of some style standards grader, a whole heap of work could have been avoided. Then again, anything to do with COBOL seems to be encumbered with a certain amount of pointlessness.

More recently I had a patch rejected from a project simply because it didn't pass an automated style checker (the code worked and tested as advertised).

What I like about (the idea of) perltidy is that even though it may not align with my personal coding style, it will at least bring everyone's style into a common melting pot, without enforcing it on anyone. So I as a coder am free to write in what ever form I'm comfortable with and pertidy can take care of making it readable to the rest of the population. I like to think my style is perfectly readable as is (or at least continually getting better with experience - I hope).

I'm considering running my personal pet projects through perltidy. Not because I necessarily believe in perltidy's definition of 'standard' (it's configurable right?), but if/when I start accepting code from other developers, I think I might like to have contributions automatically reformatted through perltidy. I think it would be counter productive to make other contributors jump through my style hoops.

Yikes! I'm flashbacking on COBOL. The heat must really be getting to me this week...

[tye]

"We did some really stupid stuff when I was writing COBOL. If we'd had something like perltidy, we could have done this really stupid stuff much, much more efficiently. We had to stop doing it because it was so expensive. If we'd had perltidy, we could have afforded to keep doing that stupid stuff much, much longer."

You make a compelling case. :)

Don't misinterpret my previous node. I don't discount that perltidy can be a huge improvement. Using perltidy as part of a two-way "let me keep my picky style and I bet you won't even notice" work flow in a group programming project strikes me as a big improvement rather like having a job in water treatment and discovering how things are tons better now that you've discovered a new tool... a snorkel for all of the times you have to swim through the sewage. Meanwhile, I refuse to keep the swimming as part of my job description and just see no benefit to having a snorkel to make it less terrible.

More recently I had a patch rejected from a project simply because it didn't pass an automated style checker (the code worked and tested as advertised).

You made a patch and couldn't be bothered to stick with the style already evident in the code? Yeah, you should certainly try to get over that problem.

It sounds like that project is doing some things rather stupidly. If one wants an inflexible robot reviewing patch submissions, then it is pretty stupid to not put that robot in the beginning of the submission process so that somebody submitting a patch knows even before they have finished the submission process that their patch violated the robot's rules and why. Of course, I'd also allow the submitter to choose to cancel or force the submission because inflexible robots often have quite lousy judgement (except in the case of very simple, clear-cut, not-error-prone, and easy-to-honor requirements).

And if one hasn't done that (yet), then one should make the whole funnel for getting to the patch submission process nearly force the submitter to realize that a "style test" will be applied and make it as trivial as possible for potential contributors to access the test tool (with all of the right settings).

In the case of a submission that the robot doesn't like, I (personally) wouldn't honor the robot's "reject" conclusion for a style violation unless 1) bringing the patched code into conformance was a pretty trivial operation and so the failure was a result of submitter ignorance and/or laziness (and ignorance often implies laziness in these situations) and so it is worth waiting a while to see if the submitter will make the trivial fixes and resubmit. Or 2) the violation was severe and so the work to "fix" the style is more than is warranted by the value of the patch.

(it's configurable right?)

Ah, so you are speaking from strong personal experience on this point.

I think it would be counter productive to make other contributors jump through my style hoops.

Sure, when it is done badly (as it seems was done to you). But perhaps you shouldn't let the one experience dominate your thinking on the matter.

I like to see other people's style and to discuss what benefits they receive and to learn. I also find it is very good to not hide from other people's styles because it helps to prevent me from becoming overly attached to personal style proclivities.

I find that last part is really valuable. I can even look at Perl code I wrote over a decade ago and hardly even notice the minor style choices that I've given up since then.

[ruzam]

Don't misinterpret my previous posts either. I didn't mean to suggest that perltidy is the end all. But I do suggest that using a tool like perltidy is a much better alternative than rigid style conformance. Being able to see other people's style and learning from it can be an unheard of luxury in many work environments (at least the majority I've been exposed to). You are indeed most fortunate.

My poorly described patch rejection example didn't help. The patch in question contained less than half a dozen lines of code, which (I thought) followed the flavour of the original. I don't even know what style guides were violated, just that the reason for the patch being dropped was that it didn't conform. My patch fixed a problem I was having with URLs generated while running the application behind a proxy. I am just a casual user of the project, contributing a fix that solved a problem for me that I thought would be useful to others, nothing more.

I can say with full confidence that I would be embarrassed to show anyone the Perl code I wrote over a decade ago :)

[tye]

Being able to see other people's style and learning from it can be an unheard of luxury in many work environments (at least the majority I've been exposed to). You are indeed most fortunate.

No, luck has only a little to do with it. I insist on good practices at the places that I work and only rarely have to work hard to overcome significant resistance to getting good practices going.

If I'm working at a place where I'm finding too much resistance, then I also work on improving the work place's general acceptance of improvements.

I'm usually quite successful. And when a workplace is beyond my ability to effectively reform, then I find a new job. But that has really only happened to me due to a corporate take-over where a powerful, established, and dysfunctional culture suddenly flowed in from the other company so that it was much better for me to move on rather than to endure the dysfunction for the time required to really make a dent in it. (This has actually happened several times but that is still quite infrequent considering the time span.)

Heck, just responding to the assertion that we must have homogenous style with frank and confident skepticism is often enough to significantly undermine the support of that assertion, in my experience.

[Anonymous Monk]

You make a lot of good points but the one I disagree with is...

You made a patch and couldn't be bothered to stick with the style already evident in the code?

If I'm a casual user of the code and I whip up something that works and is similar to the apparent style, then yeah, I can't be arsed to format it correctly for submission to your project (not at $WORK). Why should I spend hours to learn yet another set of coding standards to submit a 10 line patch just to satisfy some stupid robot? If an actual developer took a peek, he'd see exactly what the bug was... it's just silly to reject what might be a critical security fix just because some guy used tabs instead of 4 spaces.

I do understand, people submitting half-assed patches all the time is lame, but we should have a bit of patience with the random_guy@internet that actually bothered to submit a patch.

[tye]

Why should I spend hours to learn yet another set of coding standards to submit a 10 line patch just to satisfy some stupid robot?

Well I, of course, agree with that. I'm actually against putting robots in the way. And nobody said their coding standard takes hours to look up. Having an enforced coding standard that takes hours to learn is just creating a big barrier to entry (to contribution). And I don't think it would have any benefit.

Well, unless you decide to just give up on convincing people that trying to regularize very minor points of style is actually a waste of time. And that means that you waste a lot of effort on bowing to an arbitrary and expensive-to-comply-with standard. Yes, you can end each new round of the frequent nit picking by just pointing at rule 47b... well, sometimes.

But you quickly realize that there is still way too much work being wasted on just serving "the standard". So you start trying to pull in tools to help with that workload. And you probably don't notice how the joy in coding for that project has slipped away. The satisfaction of creation has been overshadowed by the constant need to bow to the exacting robot.

A much better idea is to call out nit-pickers as just that.

Or the other route advocated in this thread: Replace the rejection robot with the homogenizing robot. Yes, between those two choices, the homogenizing robot is much better (well, only in some ways).

And I agree that having no patience with half-assed patches is lame.

But my point was that I'm rather surprised that I so often see people making minor patches to a larger set of code and seeming to relatively ignore the style in the code.

When I make small changes to larger code, I follow the style already apparent in the code. And how closely I follow that style is pretty much proportional to how closely the code seems to be following one specific style.

So, if I need to add an "elsif" to the code and there aren't any "elsif"s nearby, then I'll do a quick search for "elsif"s elsewhere in the code. If they are all styled the same, then I'll be sure to style my new "elsif" like those. If they seem to all be styled very exactly the same, then I'll take a moment to pay even more attention to details.

Usually I find that there is already some variability in the style so I don't have to watch minute details.

I also see a lot of evolution of style on most long-lived projects. I've found that to usually be a very good thing.