Closed Potherca closed 7 years ago
Before making docs consider refactoring of plugin's class and entry point method's names. In my opinion they're not descriptive, especially the latter.
Both (class and method) should be named in a way like Incenteev\\ParameterHandler\\ScriptHandler::buildParameters
or Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache
.
Maybe Dealerdirect\\Composer\\Plugin\\Installers\\PHPCodeSniffer\\PHPCompatibilityPlugin::installSniffs
?
For backward compatibility you can then extend Dealerdirect\Composer\Plugin\Installers\PHPCodeSniffer\PHPCompatibilityPlugin
with Dealerdirect\Composer\Plugin\Installers\PHPCodeSniffer\Plugin
and use Plugin::run()
to call PHPCompatibilityPlugin::installSniffs()
. In future versions this could be deprecated and removed.
Valid point, will clarify the method name. As naming a thing is hard, @frenck: do you have any quams about PHPCompatibilityPlugin::installSniffs()
?
@Potherca nope, I agree with @Wirone. I feel like we need another separate issue for this.
Now when I think of it, it should not be named PHPCompatibilityPlugin
since it's not only about PHPCompatibility, but any custom standard, right?
So maybe CustomStandardsPlugin::installStandards()
?
We all know phrase about naming and invalidating cache :rofl:
Added documentation to the README, leaving the method/class rename for another issue.
Resolved by #29 will be included in the upcoming v0.4
release.
Problem/Motivation
The main functionality of this plugin (installing a custom code sniff) can be called separately (see isue #4). However, this functionality has not (yet) been documented. It could be useful for users to be made aware of this feature in the documentation.
Expected behaviour / Actual behaviour / Steps to reproduce
Does not apply
Proposed changes
Document what the future is and how it can be used.