Question

Recently we migrated to git and implemented (for now post) receive hooks on our central server to send reports to developers, as well as making several tools enabling us to have our codestandard checked automagically with phpcs on our development environments.

This is all nice and dandy, works well, but we want to be able to always depend on our code standard, not ignoring every file which does not conform for a logical reason. Now, we have our own ruleset which overrides some stuff in the default PEAR standard, but we want to go a little further if possible.

Our problem is that while the PEAR standard is perfect for all classes / business logic but in the view files we want to loosen the rules for say, closing brackets needing to be on their own line. The problem is that we mostly define html in these files and the only control structures we have are simple if-else or foreach statements, and opening php, then adding a newline, closing bracket, newline, and closing php is a bit silly imo.

Required syntax to be valid:

<?php
}
// end of some if statement ?>

What we’d instead like to use for views:

<?php } // end of some if statement ?>

This would make our code more readable…

We dislike the alternate syntax as wel (if(..): ... endif;), afaik mainly because there were some problems in validity here as well (it’s all about the whitespace…).

Ignoring the whole file (with // @codingStandardsIgnoreFile) is not an option for us.

tl;dr

So what we would like to do is define a seperate ruleset for our view files so we still have a standard to adhere to but with the relaxed rules on these fronts so our code can still be made readable.

I am not too knowledgable about phpcs yet, and couldn’t find any solutions myself using keywords I though were logical… Any suggestions to make tidy view files that also conform to PEAR are also welcome…

Answer 1

If it comes down to just a few messages you want to exclude from some files, then you can put these exclusions directly into your ruleset.xml file. For example:

<!--
  You can also be more specific and just exclude some messages.
  Please note that all message-specific ignore patterns are
  checked using absolute paths.

  The code here will just hide the ContainsVar error generated by the
  Squiz DoubleQuoteUsage sniff for files that match either of the two
  exclude patterns.
 -->
<rule ref="Squiz.Strings.DoubleQuoteUsage.ContainsVar">
  <exclude-pattern>*/tests/*</exclude-pattern>
  <exclude-pattern>*/data/*</exclude-pattern>
</rule>

I’m not sure where your view files are stored, but if you can match them using an exclude-pattern (basically just a regular expression) then you’ll be able to relax some of the rules on them.

The best way to figure out that ref=”” bit is to run phpcs on your view files and using the -s command line argument. For each message, you will get a unique code, which you can then use to add specific exclude-patterns to your ruleset.

There are a bunch of other things you can do in the ruleset files as well. Check out the docs here.