-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require empty line after class definition and before it end #3653
Comments
I don't recall that we have such an option. hm... could you please provide some details how you end up with given coding standard? is it somehow established in some community ? |
Unfortunately, I tend to think that no. This code style is used only in my own projects. Currently, I use a PHPStorm feature to fix code style: I want to have some solution, that I may include into our CI. For now, I only see a possibility to hard fork |
@keradus, @juliendufresne I want to try to implement this and send the pull request. Could you give me recommendations for implementation? I'm not quite sure how to split responsibilities now. Should I create a separate fixer for this rule or implement it as a configuration parameter of the existing one? In addition, as I understand it, I'll need to explain |
sorry for late feedback, I was having a little break in real life. |
For us it is important that fixers/rules/configuration either follow a standard like PSR (as we like to promote the usage/following of standards) or are widely used (as we are more likely to get support on the fixer when maintaining it). |
As I said before, this is not widely followed standard and it's mostly personal (our team) preference. I saw such code style in some repositories, that follows But I understand your feelings about maintenance. If you think it's not usable fixer for others than we can just keep it in our custom set of fixers. |
adding it in generic way would be tricky and I will leave decision to you ;) First of all, we don't like to have rules that can do the same, even partially. For that, here we would need to determine what would be those fixers. What is see is at least conflict with What I mainly see that to be done is to confirm which existing rule is conflicting, and then decide one by one what to do with them. Then, for conflict with |
This issue began just with these fixers. I will check it. // 10 mins later I performed some tests and found, that
Sure. I can deprecate it and rewrite as proxy to my fixer in PR. |
I think it's okay to have such behavior. |
show concrete examples |
Another test. This time I've setted up a clean environment. Input file: <?php
class Test {
public function method() {
// body
}
} Initial config: <?php
$finder = PhpCsFixer\Finder::create()
->in(__DIR__);
return \PhpCsFixer\Config::create()
->setRules([
'braces' => [
'position_after_functions_and_oop_constructs' => 'same',
],
'class_definition' => true,
'class_attributes_separation' => true,
])
->setFinder($finder); Result: <?php
class Test {
-
public function method() {
// body
}
-
} Then I got the same result for:
ONLY <?php
-class Test {
+class Test
+{
public function method() {
// body
}
} Looks like it's partially duplicating At least, now I have an answer why my fixer must have less priority than |
that's the thing. |
So, this is my suggestion:
If you agreed, then I'll rework my PR to complete this features. P.S. maybe I should change some names? |
I was just about to create a bug report for the behavior of the braces and class_attributes_separation rules as well as class_definition (like erickskrauch commented on 17 Apr). Those are not meant to enforce the removal of blank lines but currently they do. The above mentioned rules must not dictate the amount of blank lines. They should be indifferent to whether there is one or not, be it at the beginning or end of a block. I can file a bug report for that if need be. Otherwise I'd love to see this particular issue to be fixed, i.e. have the ability to require exactly one blank line at the start and end of a class body. Personally I think it'd be best to first fix the existing rules and only then create a new one, but YMMV. Please let me know if I you'd like me to separate the two issues. |
@InvisibleSmiley I'm agreed with you. But I still have no response from the core team to have any solution about final implementation, that will satisfy everyone. |
Currently there is no ability to add blank lines before/after class body, if |
@esemlabel, you may try to use our custom implementation: https://github.com/elyby/php-code-style#elyblank_line_around_class_body |
@erickskrauch, not my case, I'm using vscode extension. |
@esemlabel, but this extension can use the configuration from |
@erickskrauch, I'd like to have all clear and in one place, instead of installing additional fixes and remember to uninstall after php cs fixer updates. |
I'm waiting for any response for more than a year. Good luck :) |
This would be great. |
As this is not part of a standard or widely used in (F)OSS I prefer not that have this in the project to avoid the maintenance cost of the more complex code. IMHO this would be better fitted in a 3rd party custom fixer. |
Okay 😢 |
Drupal is an example with this standard requirement: https://www.drupal.org/node/608152#indenting , with class style: class Myclass {
use MyTrait;
public function foo(): void {
$hello = $world;
}
} |
(Coming from Drupal) Has anyone found a rule for this? I don't mind it being a third party package. Edit: Found #3688 (comment) but seems that the linked I'll move my focus there. Created issue elyby/php-code-style#11 |
See PHP-CS-Fixer/PHP-CS-Fixer#3653 (comment) See elyby/php-code-style#11 --- It's also a Drupal Coding Standards requirement. Added because Wienis with Drupal Coding Standards experience got OCD when looking at our code!
See PHP-CS-Fixer/PHP-CS-Fixer#3653 (comment) See elyby/php-code-style#11 --- It's also a Drupal Coding Standards requirement. Added because Wienis with Drupal Coding Standards experience got OCD when looking at our code!
Hi, Coming from Drupal too. Upgrading from Drupal 9 to Drupal 10 resulted in updating friendsofphp/php-cs-fixer from 3.4.0 to 3.13.1. And now the blank line after the class definition is removed but not the one at the end. I tried to add https://github.com/elyby/php-code-style#elyblank_line_around_class_body but then I have 2 lines at the end. Here is my config: https://gitlab.com/florenttorregrosa-drupal/docker-drupal-project/-/blob/10.x/scripts/quality/phpcs_fixer/.php-cs-fixer.dist.php I have checked that I can't figure out which rule is removing the blank line after class opening and the one adding the line at the end. Thanks for any help. |
|
@keradus thanks a lot!
I think this would save my life in the future too. Ok, I think I will see the options of native rules and maybe reach out https://github.com/drupol/phpcsfixer-configs-drupal, if it provides a |
So this behavior is coming from |
glad to help! also please be mindful that we are deprecating the braces fixer [in favour of few other fixers], don't push much effort to make braces work for your case, imho. |
Ok, thanks, an additional argument for me to see in "contrib" fixers. I opened discussions on drupol/phpcsfixer-configs-drupal#7 |
Hello, any news about this subject? |
with this news: #3653 (comment) If you want the decision to be reevaluated, please raise new details about how widely adopted that style is and which communities would benefit from such feature, as well as your rediness to work on it. |
The PHP version you are using (
$ php -v
):PHP 7.1.8
PHP CS Fixer version you are using (
$ php-cs-fixer -V
):PHP CS Fixer 2.11.1
The command you use to run PHP CS Fixer:
php-cs-fixer --diff --dry-run --stop-on-violation --using-cache=no -v fix
The configuration file you are using, if any:
If applicable, please provide minimum samples of PHP code (as plain text, not screenshots):
No changes
I want to have one blank line after defining the class and before closing it:
But
braces
andclass_definition
fixers do not allow to configure it. How can I suppress or configure this param?The text was updated successfully, but these errors were encountered: