Fix 'Drupal.Commenting.InlineComment.NotCapital' coding standard

Created on 5 May 2016, about 8 years ago
Updated 20 June 2024, 5 days ago

Follow-up to 📌 Fix 'Drupal.Commenting.InlineComment.SpacingAfter' coding standard Active

Part of 🌱 [meta] Fix PHP coding standards in core Active .

This relates to Drupal API documentation standards (general) → and Drupal standards for in-line code comments → .

Approach

We are testing coding standards with PHP CodeSniffer, using the Drupal coding standards from the Coder module. Both of these packages are not installed in Drupal core. We need to do a couple of steps in order to download and configure them so we can run a coding standards check.

Step 1: Add the coding standard to the whitelist

Every coding standard is identified by a "sniff". For example, an imaginary coding standard that would require all llamas to be placed inside a square bracket fence would be called the "Drupal.AnimalControlStructure.BracketedFence sniff". There are dozens of such coding standards, and to make the work easier we have started by only whitelisting the sniffs that pass. For the moment all coding standards that are not yet fixed are simply skipped during the test.

Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket. The sniff name is in the issue title. Make sure your patch will include the addition of this line.

Step 2: Install PHP CodeSniffer and the ruleset from the Coder module

Both of these packages are not installed by default in Drupal core, so we need to download them. This can be done with Composer, from the root folder of your Drupal installation:

$ composer require drupal/coder squizlabs/php_codesniffer
$ ./vendor/bin/phpcs --config-set installed_paths ../../drupal/coder/coder_sniffer

Once you have installed the phpcs package, you can list all the sniffs available to you like this:

$ ./vendor/bin/phpcs --standard=Drupal -e

This will give you a big list of sniffs, and the Drupal-based ones should be present.

Step 3: Prepare the phpcs.xml file

To speed up the testing you should make a copy of the file phpcs.xml.dist (in the core/ folder) and save it as phpcs.xml. This is the configuration file for PHP CodeSniffer.

We only want this phpcs.xml file to specify the sniff we're interested in. So we need to remove all the rule items, and add only our own sniff's rule. Rule items look like this:

<rule ref="Drupal.Commenting.InlineComment.NotCapital"/>

Remove all of them, and add only the sniff from this issue title. This will make sure that our tests run quickly, and are not going to contain any output from unrelated sniffs.

Step 4: Run the test

Now you are ready to run the test! From within the core/ folder, run the following command to launch the test:

$ cd core/
$ ../vendor/bin/phpcs -p

This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running.

Step 5: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur. You could fix all of these manually, but thankfully phpcbf can fix many of them. You can call phpcbf like this:

$ ../vendor/bin/phpcbf

This will fix the errors in place. You can then make a diff of the changes using git. You can also re-run the test with phpcs and determine if that fixed all of them.

📌 Task
Status

RTBC

Version

11.0 🔥

Component
Other  →

Last updated about 1 hour ago

Created by

🇫🇷France andypost

Live updates comments and jobs are added and updated live.
  • Coding standards

    It involves compliance with, or the content of coding standards. Requires broad community agreement.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇺🇸United States Mile23 Seattle, WA

    Patch in #39 no longer applies. Using git apply --rej shows us that all changes apply except the one to core/phpunit.xml.dist, and then passes composer phpcs. So it should be easy to reroll.

    MR in #35 seems broken.

    In an ideal world, the MR would reflect the current changes, but it might be less work just to stick with patches. Dunno.

  • Status changed to Needs review over 1 year ago
  • 🇮🇳India ankithashetty Karnataka, India

    Hello @Mile23! Could you please try against the latest core 10.1.x? The #39 patch still applies successfully.
    Also, there is no change made to file core/phpunit.xml.dist in the patch.🤔

    Restoring back to the previous state. Thanks!

  • Status changed to RTBC over 1 year ago
  • 🇺🇾Uruguay rpayanm

    I created a patch following the steps described in the IS and compared it with the patch from #39, I saw some differences, but they were discussed in the comments. So it looks good for me.

  • 🇺🇸United States xjm

    The test failure was a known random failure, so retesting and setting back RTBC.

  • 🇺🇸United States xjm

    Closing the broken MR for clarity and removing credit for it.

  • 🇺🇸United States xjm

    Is there a separate rule we can enable for comments that don't end in a period? Because a lot of these qualify.

  • Status changed to Needs work over 1 year ago
  • 🇺🇸United States xjm
    1. Etag must match.

      I think ETag is actually the canonical capitalization. The method is only named getEtag() because of our camel-casing spelling rules.

    2. I think we need to rethink how we're addressing the comments in
      core/modules/system/tests/src/Kernel/Migrate/d6/MigrateSystemConfigurationTest.php.

      For example

      • Uuid is not handled by the migration.

        This should be "UUID" when used in a sentence.

    3. Autorun is not handled by the migration.
      

      If this is used as a word in a sentence, it should be "Auto-run".

    4. Langcode and default_langcode are not handled by the migration.

      This is inconsistent. Either both langcode and default_langcode are machine names, or they should be treated as words in a sentence, i.e. "Language code" and "Default language code".

    5. For all of the above -- and other similar comments in the same file about gzip and such I think the sentence should be rephrased as:

      The 'foo' property is not handled by the migration.

      I'm not sure if it's a "property", maybe it's a "configuration" or a "settting" or something else. Use the appropriate noun in context.

    6. // suggestionnotimplemented() is not an implemented theme hook so

      I could not find suggestionnotimplemented() anywhere in our API. It appears to be test data used in ThemeTest and RendererTest. The CSpell issues will need to fix this eventually, but just adding parentheses is fine for now.

    7.     // Allow + for or, , for and
      

      Uh, what? Reading the code, I think this means:

      // Allow '+' for "or". Allow ',' for "and".
      

      (Though who would think + meant "or"?) Anyway. Followup for this.

    8.     // Init the table queue with our primary table.
      

      This needs to use the full word, "Initialize".

    9. There is an out-of-scope hunk in core/modules/views/tests/src/Unit/Plugin/field/FieldPluginBaseTest.php adding string typehints to a method.

    10. That same class rewrites a data provider to use meaningful array keys rather than inline comments on the cases, which is a good change. That could be handled in a separate, blocking issue to make things easier.

    11. The hunks in core/modules/views/views.api.php are weird; we have the sentence fragments:
      // Although the table aliases will be different.

      I looked at this in context and the inline comment before the code snippet is:

        // If you've decided an automatic join is a good idea, here's how to do it;   
        // the resulting SQL query will look something like this: 
      

      So, I think we should changes these two to:

      // (The table aliases will be different.)
      
    12.     // Todo mock a request with a route.
      

      This should actually be changed to:

          // @todo Mock a request with a route.
      
  • 🇮🇳India Aadhar_Gupta

    Changes described in comment number 49 have been applied.

    Here is the patch and inter-diff for the same -

  • Status changed to Needs review over 1 year ago
  • Status changed to Needs work over 1 year ago
  • 🇺🇸United States xjm

    Very little of #49 is actually addressed, at least based on the interdiff posted.

  • 🇳🇿New Zealand quietone New Zealand

    Converted to an MR, ran phpbcf and then started work on #49.

    #49.
    1. Fixed
    2. The first two are changed as asked for. The third corrects 'Langcode' but does not rework the sentences to use quotes around the variable names. I agree that it is correct and we are touching that line but I stopped because of the comment suggests it be done in the rest of the file. That would be out of scope. Even with inconsistencies across files I prefer to keep the style of comments in a file the same for readability.
    3. Fixed in 📌 Correct spelling of words in module core/tests Fixed
    4. Still needs a followup.
    5. Fixed.
    6, 7 No longer relvant
    8. No change. The suggested change doesn't make sense to me at this late hour.
    9. Fixed

  • Status changed to Needs review 14 days ago
  • 🇳🇿New Zealand quietone New Zealand

    #49.
    4. Fixed.
    8. Fixed

  • 🇺🇸United States smustgrave

    Of the points in #49 only 49.2 was one I had a question on. Left the question in the MR but will leave in review for others.

  • Status changed to Needs work 6 days ago
  • The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

    This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

    Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

  • Status changed to Needs review 5 days ago
  • 🇳🇿New Zealand quietone New Zealand
  • Status changed to RTBC 5 days ago
  • 🇺🇸United States smustgrave

    My one comment/concern has been answered. Believe this is good

Production build 0.69.0 2024