1.0.0-beta.7 returns the "Line 0 exceeds 100 characters" warning message instead of the actual line number.

For example this code that was located on line 86

$script = (new Script(self::HANDLE_EDITOR, $assetUri . "$fileName.js", Asset::BLOCK_EDITOR_ASSETS))->withFilePath($assetDir . "$fileName.js")

returns this message

FILE: AssetProvider.php
-----------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------------------
 86 | WARNING | Line 0 exceeds 100 characters; contains 142 characters.
-----------------------------------------------------------------------------------------------------------------

This brach if merged will:

• Modernize the codebase:

  • Move from PSR-2 or PSR-12
  • Use latest PHPCS
  • Use latest WPCS
  • Use latest VIP CS now in separate repo from WPCS

• Cleanup:

  • Remove custom and 3rd party sniffs that are duplicated
  • Remove PHPCSAliases.php that's no more necessary
  • Remove arg and config from ruleset.xml

Improve:

• Make customization of ElementNameMinimalLength sniff
• Improve detection of hook callback

Overall, merging this PR will fix:

• #21
• #25
• #26 (some outdated packages will be there because of PHPUnit 6 that we need due to PHP 7.0 support)
• #29
• #33

So basically all open issues.

Before merging this has to be tested in the real world, that is, the updated repo as to be used to check a few WP codebases.

When merged we can release v0.15 which could be the 1.0-beta.

The Problem

When running unit tests, I see over 30 errors saying that classes like Translationmanager\Exception\UnexpectedEntityException are not found. Further up in the output, I see raw PHP code for those classes, like so:

.....E<?php# -*- coding: utf-8 -*-

namespace Translationmanager\Exception;

/**
 * Class InvalidPostException
 */
class UnexpectedEntityException extends EntityException
{
    /**
     * Create a new Exception for Unexpected Post Value Retrieved
     *
     * @param string $postType
     * @param string $message
     * @return UnexpectedEntityException
     */
    public static function forPostValue($postType, $message)
    {
        $message = $message ?: "Unexpected post value retrieved for post type {$postType}";

        return new self($message);
    }

    /**
     * Create a new Exception for Unexpected Term Value Retrieved
     *
     * @param mixed $value
     * @param string $message
     * @return UnexpectedEntityException
     */
    public static function forTermValue($value, $message)
    {
        $valueType = is_object($value) ? get_class($value) : gettype($value);
        $message = $message ?: "Unexpected term value retrieved. Should be WP_Term but got {$valueType}";

        return new self($message);
    }
}

Possible Cause

The start of comment sequences // or # are too close to the opening PHP tag <?php. This makes the interpreter misinterpret the files included by autoloading as text instead of PHP.

Suggested Solution

Amend the rules to include a space between the starting PHP tag and the encoding declaration comment.

Specs

• PHP: 7.1;
• PHPUnit: 7.5.20;
• inpsyde/php-coding-standards: 38546e64d1f04fb69d7105bfe41ef9e46c6f8bfb.

I tried to install the package via composer, but it failed with some errors:

>composer require inpsyde/php-coding-standards --dev
Using version ^0.13.4 for inpsyde/php-coding-standards
./composer.json has been created
Running composer update inpsyde/php-coding-standards
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - dealerdirect/phpcodesniffer-composer-installer[v0.4.0, ..., v0.4.4] require composer-plugin-api ^1.0 -> found composer-plugin-api[2.0.0] but it does not match the constraint.
    - inpsyde/php-coding-standards 0.13.4 requires dealerdirect/phpcodesniffer-composer-installer ^0.4 -> satisfiable by dealerdirect/phpcodesniffer-composer-installer[v0.4.0, ..., v0.4.4].
    - Root composer.json requires inpsyde/php-coding-standards ^0.13.4 -> satisfiable by inpsyde/php-coding-standards[0.13.4].

You are using Composer 2, which some of your plugins seem to be incompatible with. Make sure you update your plugins or report a plugin-issue to ask them to support Composer 2.

Installation failed, deleting ./composer.json.

I'm using Windows 10, PHP 7.3.24, Composer 2.0.8

I cloned the package from github repository.
"composer install" have worked fine. It works normally in this way of installation.

The Inpsyde sniff (https://github.com/inpsyde/php-coding-standards/blob/master/Inpsyde/Sniffs/CodeQuality/ReturnTypeDeclarationSniff.php#L175) for check id return type is existing works only for method, like

public function get_media_strings(array $strings): array and not for functions, without a property visibility.

However if it will fail if is a function, without class, only namespace usage, then will the sniff get an error message ' Return type is missing'.

function get_media_strings(array $strings): array

Currently I get PossiblyStaticClosure warnings even in code outside of classes, such as here.

I think it should not happen, in this context there is no way to access $this anyway, so no reason to add static.

Sometimes it is required to implement get/set or whatevery methods which are maybe not allowed by coding standard but fixed by an interface.

Following error occurs in version 0.7.x - release:

Getters are discouraged. "Tell Don't Ask" principle should be applied if possible, and if getters are really needed consider naming methods after properties, e.g. name() instead of getName().(InpsydeCodingStandard.CodeQuality.NoAccessors.NoGetter)

As code example we've following:

<?php declare(strict_types=1); # -*- coding: utf-8 -*-

class Foo implements IteratorAggregate
{


    public function getIterator(): Traversable
    {
        // snip
    }
}

Link: http://php.net/manual/en/iteratoraggregate.getiterator.php

Secondly it could be also possible to e.G. implement PSR-standard interfaces like PSR container which are having a get($id) method.

I'm getting following error message with the latest 0.7.x - release:

Line exceeds 120 characters; contains 130 characters (InpsydeCodingStandard.CodeQuality.LineLength.TooLong)

But this is for a comment which contains a link:

/**
 * Returns the <noscript>-tag for GTM.
 *
 * @link https://developers.google.com/tag-manager/devguide#adding-data-layer-variables-for-devices-without-javascript-support
 *
 * @return string
 */

This rule shouldn't test for comments.

If we should, do it use this repo, please remove the current files (https://github.com/inpsyde/Codex/tree/master/tools/CodeSniffer) on the codex repository so that we not have an redundant standards. Maybe we should leave a hint in the codex repo for that new ruleset.

Inpsyde.CodeQuality.ReturnTypeDeclaration.NoGeneratorReturnType complains about the following:

public function listSomething(): iterable {
     yield 1;
     yield 2;
}

I'm not sure if iterable suggests a rewinding of the returned list because that wouldn't be possible. If not, this construct should be allowed IMO.

Please consider upgrading versions

$ composer outdated
dealerdirect/phpcodesniffer-composer-installer v0.4.4 v0.5.0 PHP_CodeSniffer Standards Composer Installer Plugin
phpdocumentor/reflection-common                1.0.1  2.0.0  Common reflection classes used by phpdocumentor to reflect the code structure
phpdocumentor/type-resolver                    0.4.0  1.0.0
phpunit/php-code-coverage                      5.2.0  7.0.7  Library that provides collection, processing, and rendering functionality for PHP code coverage...
phpunit/php-file-iterator                      1.4.5  2.0.2  FilterIterator implementation that filters files based on a list of suffixes.
phpunit/php-timer                              1.0.9  2.1.2  Utility class for timing
phpunit/php-token-stream                       2.0.2  3.1.0  Wrapper around PHP's tokenizer extension.
phpunit/phpunit                                6.0.13 8.3.1  The PHP Unit Testing framework.
phpunit/phpunit-mock-objects                   4.0.4  6.1.2  Mock Object library for PHPUnit
Package phpunit/phpunit-mock-objects is abandoned, you should avoid using it. No replacement was suggested.
sebastian/comparator                           2.0.0  3.0.2  Provides the functionality to compare PHP values for equality
sebastian/diff                                 1.4.3  3.0.2  Diff implementation
sebastian/environment                          2.0.0  4.2.2  Provides functionality to handle HHVM/PHP environments
sebastian/global-state                         2.0.0  3.0.0  Snapshotting of global state
sebastian/resource-operations                  1.0.0  2.0.1  Provides a list of PHP built-in functions that operate on resources
wp-coding-standards/wpcs                       0.14.1 2.1.1  PHP_CodeSniffer rules (sniffs) to enforce WordPress coding conventions

Is your feature request related to a problem?

After code refactoring or merging, we often have redundant namespace imports with the use keyword. This is a dead code that does nothing but pollution. It's easy to overlook these lines.

Describe the desired solution

Add a sniff raising warning or error on redundant namespace imports.

Describe the alternatives that you have considered

Require the code standard with this rule and just use it.

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Is your feature request related to a problem?

Can't update/install over PHPCS standards that require latest php_codesniffer version.

Describe the desired solution

Currently squizlabs/php_codesniffer is locked at ~3.6.0, but now suggests 3.* or latest is now 3.7.1.

Describe the alternatives that you have considered

??

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Is your feature request related to a problem?

Currently, there is no rule that checks whether there is a space after the type casting. As a result, several spellings exist.

Without a space:

return (int)$lowStockThreshold;

With spaces:

return (string) max($lowStockThresholds);

Describe the desired solution

Add a rule that checks that there is a space after the type casting.

Describe the alternatives that you have considered

None.

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Describe the bug Not sure if this bug should be tackled in here

Some auto fixing is not working as expected Notice the phpdeclare at the right after running phpcbf

To Reproduce Steps to reproduce the behavior: Have the following file with code:

<?php declare(strict_types=1); // -*- coding: utf-8 -*-
/*
 * This file is part of @package CCV\ElasticWPCustomizations
 *
 * (c) Inpsyde GmbH
 *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

namespace CCV\ElasticWPCustomizations\Tests\Unit\Index\Mapping\Settings;

Expected behavior

System (please complete the following information):

• OS: Ubuntu
• PHP Version 7.4-fpm under docker container

Is your feature request related to a problem? Please describe. At Inpsyde, PHP files used to have the following file header:

<?php # -*- coding: utf-8 -*-

or

<?php declare(strict_types=1); // -*- coding: utf-8 -*-

As of 2021-06-25, there are more than 15.000 PHP files with this header. It originates from Emacs and including it was adapted by developers undiscussed for years.

However, (nowadays) it doesn't make any sense to keep it. In fact, it is no longer used in most new packages and should be removed gradually from legacy packages too.

Describe the solution you'd like

• Add a coding standard check for the header that warns the user if the header is present.
• Make sure that phpcbf deletes it.

Describe alternatives you've considered None.

Additional context None.

Is your feature request related to a problem? Please describe. This is more a question:

Would it be a good idea to throw an error or a warning when the priority argument of add_action and add_filter is PHP_INT_MAX or PHP_INT_MIN?

Describe the solution you'd like phpcs throwing a warning or an error.

Describe alternatives you've considered

Additional context Someone wrote "I do not like the usage of PHP_INT_MAX for the hook order, because it is not possible to remove them with another plugin. Yes, maybe not relevant in this case of custom plugin for a customer, but see it too often and have no chance to remove them silently."

Also wrote "But good style in coding is not always a topic of rules and standards, more a process of learning. The value for php int max is always different and is dependent from the client, from the machine."