Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
Morbus IffAs 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).
Comment #2
Morbus IffThe 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 withforeach ($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".)Comment #3
abraham CreditAttribution: abraham commented