Re: Re: PHP_CodeSniffer: Patchlevel updates break our Coding Standards

To keep things technical, can you elaborate more by what you mean about 
cherry-picking specific sniffs?

What's the advantage of providing packaged standards if you should be 
specifying each sniff within the standard you want to use? Are they 
primarily organizational?

Should the <exclude> option be removed or deprecated to prevent problems 
like the one Christian encountered? The online documentation contains an 
example much like Christian's without any warning of it's negative 
consequences:

http://pear.php.net/manual/en/package.php.php-codesniffer.annotated-ruleset.php

Cheers,
Mike


On 27/02/2013 6:33 PM, Greg Sherwood wrote:
> Well I was offended by the way I was approached and it is unreasonable for
> anyone to tell me how to feel.
>
> I also answered the issues of the generic coding standard and versioning in
> general. I feel I provided enough information to solve Christian's problem
> right now, and to make his standard more future-proof. I don't know how
> this can get any more technical. It's a pretty high-level discussion.
>
> Greg
>
>
> On Thu, Feb 28, 2013 at 9:18 AM, Ferenc Kovacs <[email protected]> wrote:
>
>>
>>
>>
>> On Wed, Feb 27, 2013 at 10:34 PM, Greg Sherwood <[email protected]>wrote:
>>
>>> 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
>>>
>>
>> Hi,
>>
>> I couldn't find anything offensive in the original mail, and while I agree
>> that maybe sending you a private mail would have been more discrete, but
>> your reply seems to be pretty knee-jerk and aggressive imo.
>> Could we discuss this on the technical level, putting personal feelings
>> aside and without insulting each others?
>> Thanks for your understanding and your work on the packages is much
>> appreciated! _o_
>>
>>
>> --
>> Ferenc Kovács
>> @Tyr43l - http://tyrael.hu
>>
>
>
>


-- 
PEAR General Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php