[PEAR-BUG] Bug #20357 [Fbk]: The "FunctionComment" mistaking DocBlock comments

[email protected]
Newsgroups php.pear.bugs
Message-ID <[email protected]>
Edit report at https://pear.php.net/bugs/bug.php?id=20357&edit=1

 ID:               20357
 Updated by:       [email protected]
 Reported By:      aik dot bold at gmail dot com
 Summary:          The "FunctionComment" mistaking DocBlock comments
 Status:           Feedback
 Type:             Bug
 Package:          PHP_CodeSniffer
 Operating System: Linux
 Package Version:  1.5.3
 PHP Version:      5.4.20
 Assigned To:      squiz
 Roadmap Versions: 
 New Comment:

> Instead of overriding the process() method, it may actually be better
to just include 
the sniff as is, then mute the ShortNotCapital error in your custom
coding standard. 
Then you can include a custom sniff that only checks this one thing.

Yes, that maybe a solution indeed. Error hiding by code is done through
setting 0 severity if I'm not mistaken. Hopefully in 2.x 
version the original Squiz_Sniffs_Commenting_FunctionCommentSniff is
checking for exact same things as it's version in 1.x.
However I still need to use CommentParser->getShortComment() to get the
short comment to validate. Is there any possibility to 
keep CommentParser class with it's public API, but in 2.x it will just
do token-based analysis. This way whoever are using it in 
sniffs won't need to change much.

> You've also modified the code that checks the return tag, so you could
mute a 
bunch of errors in there as well.

Same approach as with short comment check. That sounds good.

> Or, to make it slightly better, you could write a custom sniff that
includes and runs 
the new DocCommentSniff only if running on 2.x.

1. In the ruleset.xml we can always include
Squiz_Sniffs_Commenting_FunctionCommentSniff and mute "ShortNotCapital"
error 
(that won't match to any error from 2.0 version of this sniff though)
2. Create sniff that will check for short description of a function
(ways of obtaining short description differs from 1.x and 2.x and 
that's a problem)
3. create a clever sniff, that will determine PHPCS version used and:
- for 2.x include DocCommentSniff instead of it (with muted error
message for "ShortNotCapital")
- for 1.x do nothing
- we can't mention "DocCommentSniff" in ruleset.xml I guess, because
this would result in Exception in PHPCS 1.x

Problem with @return tag processing stays. It's the
Squiz_Sniffs_Commenting_FunctionCommentSniff which is aware:
- when function comment starts and passes that stack pointer to
"processReturn"
- how to get return content

Having some migration layer that will use tokens for 2.x and
CommentParser for 1.x is still needed I'm afraid.


Ideas?


Previous Comments:
------------------------------------------------------------------------

[2014-08-14 07:00:40] squiz

Should also say, if it is easier, contact me directly at: gsherwood at
squiz dot com dot 
au

------------------------------------------------------------------------

[2014-08-14 07:00:05] squiz

Sorry it's taken so long, but I have taken a look at the function
comment sniff and I 
can see what you've changed.

The bad news is that the sniff is drastically different in 2.x, to the
point where most 
of the checks actually live in a different sniff now: 
https://github.com/squizlabs/PHP_CodeSniffer/blob/phpcs-
fixer/CodeSniffer/Standards/Generic/Sniffs/Commenting/DocCommentSniff.php

Instead of overriding the process() method, it may actually be better to
just include 
the sniff as is, then mute the ShortNotCapital error in your custom
coding standard. 
Then you can include a custom sniff that only checks this one thing.

You've also modified the code that checks the return tag, so you could
mute a 
bunch of errors in there as well.

But the worse news is that doing this, while cleaner, means that you
would need a 
different ruleset.xml file for 1.x and 2.x.

Or, to make it slightly better, you could write a custom sniff that
includes and runs 
the new DoCommentSniff only if running on 2.x.

I'd need to have a bit of a play around to get something going. Before I
do, does 
this sound like something you would considered doing? Specifically:
- including all of the Squiz (or PEAR) FunctionCommentSniff but turning
off some of 
the errors
- including the DocCommentSniff in your standard, probably via a custom
sniff
- including a custom sniff (probably the same one as above) that checks
your event 
function short descriptions

BW, I haven't checked the inline comment sniff yet.

------------------------------------------------------------------------

[2014-08-07 09:53:01] aik099

Link in above comment has been wrapped by pear bug tracker and became
broken as 
a result. Beware.

Actually if it's easier for you, then you can compare the Squiz/PEAR
version of 
FunctionComment sniff to mine, then you'll note some minor differences.
This way 
might be easier to determine what needs to be changed.

------------------------------------------------------------------------

[2014-08-07 09:07:43] aik099

That would be wonderful. Thanks upfront.

Here they are: 
https://github.com/aik099/CodingStandard/tree/master/CodingStandard/Sniffs/Comm
enting

You can just send Pull Request with updated version there.

Sniffs have corresponding tests, so you will know if something was
broken by accident 
during transformation.

------------------------------------------------------------------------

[2014-08-07 03:37:55] squiz

The 2 versions use different tokens, so you should be able to detect
which version of 
the sniff to use. If you want to send me the custom sniffs you have,
I'll convert them 
over for you and make sure I can detect both versions.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=20357

-- 
Edit this bug report at https://pear.php.net/bugs/bug.php?id=20357&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.