Consider using more opinionated defaults

[jdufresne]

PHP-CS-Fixer is an excellent tool that has helped to create a consistent code style across projects and reduce unnecessary bike shedding over ultimately unimportant details. Thank you!

However, I think it could take one step further and ship with more opinionated defaults.

The success of tools such as prettier, gofmt and black suggest that projects appreciate these opinionated tools.

PHP-CS-Fixer currently ships with a relatively small amount of defaults and leaves the rest up to end users to configure. This configuration shifts the bike shedding from a code style document to a configuration file. Today, if projects choose to use the defaults, many aspects of code formatting remain untouched by PHP-CS-Fixer such as extra blank lines between statements, unused use statements, use statement ordering, and many more. If PHP-CS-Fixer were to ship more opinionated defaults, projects may be more willing to simply accept these defaults and avoid the need to waste time deciding which rules to accept and configure.

Beyond helping individual projects avoid bike shedding, I think it would also help the wider PHP community. If the opinionated defaults were to become commonly accepted, more PHP projects would use a similar or identical code style. Contributors would easily switch from project to project with less friction as they wouldn't need to think or research the individual project's preferred style. In my experience, this has been the case for other languages and communities.

One potential approach would be to change the default configuration to @Phpcsfixer or to introduce a new @default group of options with all style options turned on.

This suggestion isn't to remove the ability to configure PHP-CS-Fixer only to change from a small amount of defaults to an opinionated set.

I recognize that this would be considered a backwards incompatible change, so it might be best to only consider when releasing a new major version.

I also recognize that this suggestion may be controversial or not accepted and that is fine, not a big deal, but thought I'd throw this idea out there. Either way, thank you!

[jdufresne]

An interesting article on the subject: https://www.jackfranklin.co.uk/blog/letting-tools-make-choices/

[Wirone]

I completely agree with you. Default config (marketed as "opinionated coding style") was one of the pillars of Laravel Pint's success. I believe PER-CS v2 should be default configuration to apply, but:

• what about finder config (use src and tests as default? Fix all PHP files in the current directory and subdirectories)?
• we don't even have complete PER-CS v1 ruleset, not to mention v2 😩 (PSR-12 / PER-CS v1 Support #4502, minor: Update PER set to v1.1 #6547)

I think we should create milestone for that, create all necessary issues in it, and then deliver 😉. Or one issue with checklist, whatever - anything that can help with tracking the progress.

[keradus]

Back in past, we had a default that was @Symfony (where we grow from!). It was really limiting the audience of the tool and the audience grow when we set default framework-agnostic (meaning we were not recommending a default that mimics given ecosystem (ie this or that framework), but well established standards (PHP-Fig). We are a somehow behind newest PER-CS (we focused on PHP 8.x compatibility instead). I wonder if having this up to date wouldn't be good enough.

btw, the @PhpCsFixer is way more opinioated than the @Symfony, nowadays

Finder - in __DIR__, exclude ./vendor/ ?

[Wirone]

Finder - in __DIR__, exclude ./vendor/ ?

Seems reasonable 👍.

In terms of PER-CS, I've created #7247 so we can track progress there. When we have PER-CS v2 ready, we can think about opinionated defaults (#7248).

[keradus]

I was also thinking to have some kind of "wizard", which would be autosuggesting the rulesets (eg which PHP? ok, so this ruleset. using phpnit? maybe want to use the set for it too" etc)

[Wirone]

I recognize that this would be considered a backwards incompatible change, so it might be best to only consider when releasing a new major version.

Why would it be incompatible? It would be new feature, not conflicting with how Fixer works currently. Right now configuration file is required to run it, so people who currently use Fixer have config file in place (so it will work exactly the same). For new projects it would just run with default config and creating config file would totally override it.

Maybe you considered config should extend default config, and yes, then it would be breaking change because people's config would have different base for resolving final rule set. But we could introduce this strategy in v4 (or configurable strategy: choose between starting from scratch or extending default config).

In any case, I see it as totally possible in v3 without BC break 🙂.

[keradus]

Above is not right.

@Wirone , it is already possible to run PHP CS Fixer without any config file:

ker@d ~/github/random-project λ ./vendor/bin/php-cs-fixer fix -v .
PHP CS Fixer 3.25.1 Crank Cake by Fabien Potencier and Dariusz Ruminski.
PHP runtime: 8.2.8
Loaded config default.
.FF.FFFFFF..........................................F..

Right now, the defaults are:

• PSR12 ruleset, ref https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/master/src/Config.php#L60
• *.php except /vendor, ref https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/master/src/Finder.php#L31-L32
  • yet it is still required to provide folder to run process for (the . argument to command I shared)

thus, the feature (should be possible to just run vendor/bin/phpcsfixer (or using PHAR) without creating any configuration file) already exists, simply with somehow old defaults

[Wirone]

@keradus for the record: it's possible, but it's not user friendly. It's not intuitive, because when you look at fix --help you can see fix [options] [--] [<path>...], paths are optional.

So basically we would need to:

• Fix Display specific error message when no config is found #5288 so there's clear error about the need of providing either explicit paths to fix command OR config file with proper finder
• Update defaults to @PER-CS
  • -=> feat: change default ruleset to @PER-CS (only behind PHP_CS_FIXER_FUTURE_MODE=1) #7650
• set project's root dir as a default directory to process (be careful about --path-mode)

How does it sound for you?