Re: PHP_CodeSniffer: Patchlevel updates break our Coding Standards

Christian,

It seem you have misunderstood the purpose of the generic sniffs. The way
to use them is to cherry pick the ones you want; not to include the whole
bucket of sniffs and then exclude the ones you don't. They are unrelated,
and many conflict with each other. So I suggest you swap around to this
model and you wont have any problems with the code I release as you will be
in full control of your standard.

Adding a new generic sniff is not akin to adding a new feature to the core
product, and I am quite happy with the way versions are working right now.
I haven't had anyone else become confused about it and I always put out
plenty of information when I am breaking backwards compatibility, such as
the not-so-recent change to the way custom coding standards were defined
and the current 1.5 release that rewrites the reporting engine. These are
not entire product rewrites (PHPCS still functions in the same way), but
they are potential BC breaks for some developers and so I put out RCs and
articles to help migrate. I think I'm doing a pretty good job in this area
and find your email quite insulting.

But I suspect you wouldn't be concerned about versioning at all if you
change the way your standard is constructed.

Due to the way you've chosen to go about creating your standard, you've
obviously been angry for quite a few releases (I add generic sniffs quite
often) and decided to vent your frustration by lecturing me on a public
mailing list. I'm not sure why you felt this was the best way to
communicate with me. Everyone else seems to be able to get in touch with me
without feeling the need to include a much wider audience. Next time you
think you have a problem with me or any code I maintain, I'd appreciate it
if you would come to me directly.

Greg


On Wed, Feb 27, 2013 at 10:03 PM, Christian Weiske <[email protected]>wrote:

> Hi,
>
>
> We've build our own coding standard on top of the Generic and PEAR
> coding standards:
>
> > <ruleset name="NRT3">
> >   <rule ref="Generic">
> >     <exclude name="Generic.Classes.DuplicateClassName" />
> >      ...
> >   <rule ref="PEAR">
> >     <exclude name="PEAR.Files.IncludingFile" />
> >     ...
> >   </rule>
> >
> >   <rule ref="Netresearch" />
> >
> >   <exclude-pattern>*/ext_emconf.php</exclude-pattern>
> > </ruleset>
>
> With nearly every PHP_CodeSniffer patchlevel release, we had to adjust
> our own coding standard because the rules changed.
>
> Most recently, 1.4.4 added a
> > "php files must not contain newlines at the end"
> sniff, which meant we had to adjust our standard again.
>
> PEAR's backwards compatibility[1] rules are very strict, and they are
> something I could always rely on. PHP_CodeSniffer seems to have broken
> with this model.
>
> Greg, please use patch level updates for bug fixes, not to introduce
> new features. Use feature level updates to introduce them.
>
> The PEAR rules are basically the same as what's now known as "semantic
> versioning"[2] and widly supported.
>
> x.y.z
> - change in x: big changes/rewrite
> - change in y: new features level
> - change in z: bug fixes
>
> [1] http://pear.php.net/group/docs/20040226-vn.php
> [2] http://semver.org/
>
> --
> Regards/Mit freundlichen Grüßen
> Christian Weiske
>
> -= Geeking around in the name of science since 1982 =-
>



-- 
Greg Sherwood
Chief of Engineering
[email protected]

Squiz Labs Pty. Ltd. Suite 4, 7 Parkes St Parramatta NSW 2150
P  +61 2 9045 2800   W  www.squizlabs.com