While it doesn't necessarily follow the strict letter of the guideline, it would be nice if a comment could end with a closing parenthesis, e.g.
function views_ui_add_limited_validation($element, FormStateInterface $form_state) {
// Retrieve the AJAX triggering element so we can determine its parents. (We
// know it's at the same level of the complete form array as the submit
// button, so all we have to do to find it is swap out the submit button's
// last array parent.)
// Look through the child properties to find the data reference
// property that should be the "real field" for the relationship.
// (For Core entity references, this will usually be ":entity".)
Currently you'll get complaints for both the DocCommentSniff and the InlineCommentSniff (at least that I've noticed), but it's valid English and I think it follows the spirit of the guideline.
Comments
Comment #2
drunken monkeyStrongly in favor of that, having to rewrite it is ridiculous.
Either a closing paranthesis should always be allowed, or there needs to be a clever way to check for this exception.
Comment #3
kevin.dutra commentedHere's a simple change to allow the closing paren.
Comment #4
klausiCould you provide some real world comment examples in the issue summary? I'm not convinced by the example.
Comment #5
borisson_I added a couple of places where we are having issues with this rule in search api.
Comment #6
kevin.dutra commentedReplaced my original sample with an example out of core (8.0.5).
Comment #7
klausiOK, removed one example that does not end in a ")".
I think the "(...)" part of a comment should be the last part of a sentence followed by a dot, but I guess people might want to do it differently.
Anyone want to supply a patch to allow ")" as ending character?
Comment #8
borisson_@klausi, is the patch in #3 not sufficient?
Comment #9
klausiAh, sorry, overlooked the patch. Almost ready, it only needs a test case in good.php.
Comment #10
borisson_Comment #11
klausiphpunit is failing:
Comment #12
kevin.dutra commentedI think this should button up those couple items.
Comment #14
klausiCommitted, thanks!
Comment #15
borisson_Awesome, thanks @klausi!
Comment #16
borisson_Not sure if I should've opened another issue for this, but this is also valid for parameter comments.
Comment #17
drunken monkeySomething aweful seems to have happened to your patch there.
Comment #18
borisson_Comment #19
anoopjohn commentedShouldn't the following be the cases
Good
1) This is a sentence with some text in bracket at the end and a full stop after that (this is the text in the bracket).
2) This is a first sentence with a full stop at its end. (This is a full sentence inside a bracket with full stop inside the bracket.)
Bad
1) This is a sentence with text in the bracket at the end but not ending in a full stop after the bracket (this is the text in the bracket)
2) This is a first sentence with a full stop at its end. (This is a full sentence inside a bracket but no full stop)
3) This is a first sentence without a full stop (This is a full sentence inside a bracket but no full stop)
I do not think we will be able to detect if the text before the bracket is a full sentence or not. Same for the text inside the bracket.
So the cases we can programmatically test are
a) If there is no full stop just before the opening bracket then there should be a full stop after the closing bracket.
b) If there is a full stop just before the opening bracket then there should be a full stop inside the closing bracket or outside the closing bracket
Auto correct could be
a) If there is no full stop just before the opening bracket and there is no full stop after the closing bracket then add a full stop after the closing bracket.
b) If there is a full stop just before the opening bracket and there is no full stop inside the closing bracket or outside the closing bracket then add a full stop after the closing bracket.
Comment #20
drunken monkeyThat's invalid English grammar. If the whole sentence is inside the parentheses, why would you have the terminating period outside it? (It also looks silly).
But of course, checking for a stop (or exclamation/question mark) before the closing parenthesis (or parentheses, as may be the case) would make sense, and the results probably even more reliable. It would just be much more work, so I think first avoiding false positives is a sensible decision, before maybe improving this rule further.
Comment #22
klausiAgreed with drunken monkey.
Committed the patch, thanks!
Comment #24
anoopjohn commentedDocumenting this here
https://www.drupal.org/drupalorg/style-guide/content#punctuation
From https://www.drupal.org/node/1354#drupal
We may have to re-look at the autocorrect for periods when there are closing brackets involved. The standards say that closing brackets should either have a period before it or after it if it is the last character in a sentence.