I think one of the obsessively anal wisdoms of history is when a module just builds on existing functionality and is not offering unique value on its own (such as this module, which just ships with some more strict rules then coder), it should instead be a patch against the original module. Why not?

Comments

Morbus Iff’s picture

As stated in the CTL's module's description, Coder focuses on rules that nearly everyone can agree on - they're written down and part of the "official" code style guidelines. My biggest concern is that the anality of the rules would cause Coder to become less valuable - that people would think it complains TOO much, or that any one particular rule is up for "discussion". I have no doubt that some of these rules could be ported to Coder core. But all of them? I just don't see that happening.

For instance, one of the rules I'd like to add in the future is a complaint against any use of constants that do not have numeric values. That'll cause a shitstorm with some people (as it already has both in the issue queues, and on the existing Drupal Tough Love posts).

Morbus Iff’s picture

The other issue is that some rules are /really tough/ to get no "false positives" on like, say, the "e-mail" vs "email" issue. Currently, the Tough Love rule checks every code line, which means $webform['email'] will be yelled at, along with foreach ($emails as $email) and CiviCRM's "email" usage. Should Coder ship with the admonition that it will cause false positives, like Coder Tough Love does? (This is quite deliberate, actually - I advocate all of the above turning into "mails" and "mail".)

abraham’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.