| Conditions | 1 |
| Paths | 1 |
| Total Lines | 51 |
| Code Lines | 38 |
| Lines | 0 |
| Ratio | 0 % |
| Changes | 1 | ||
| Bugs | 0 | Features | 0 |
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
| 1 | <?php |
||
| 25 | protected function configure() |
||
| 26 | { |
||
| 27 | $this->setName(self::COMMAND_NAME); |
||
| 28 | $this->setDescription("Check the style of commit messages in a pull request"); |
||
| 29 | |||
| 30 | $help = ''; |
||
|
|
|||
| 31 | $help .= "Evaluates a the commits in a pull request and checks that their messages match the style advised by "; |
||
| 32 | $help .= "Git. It will then update the \"status\" in github (that little dot next to the commits).\n"; |
||
| 33 | $help .= "\n"; |
||
| 34 | $help .= "\n"; |
||
| 35 | $help .= "Here are some good articles on commit message style:\n"; |
||
| 36 | $help .= "\n"; |
||
| 37 | $help .= "* http://chris.beams.io/posts/git-commit/\n"; |
||
| 38 | $help .= "* https://git-scm.com/book/ch5-2.html#Commit-Guidelines\n"; |
||
| 39 | $help .= "* https://github.com/blog/926-shiny-new-commit-styles\n"; |
||
| 40 | |||
| 41 | $this->setHelp($help); |
||
| 42 | $this->setDefinition( |
||
| 43 | new InputDefinition( |
||
| 44 | [ |
||
| 45 | new InputArgument( |
||
| 46 | self::ARGUMENT_GITHUB_USERNAME, |
||
| 47 | InputArgument::REQUIRED, |
||
| 48 | 'GitHub Username' |
||
| 49 | ), |
||
| 50 | new InputArgument( |
||
| 51 | self::ARGUMENT_GITHUB_REPOSITORY, |
||
| 52 | InputArgument::REQUIRED, |
||
| 53 | 'GitHub Repository' |
||
| 54 | ), |
||
| 55 | new InputArgument( |
||
| 56 | self::ARGUMENT_PULL_REQUEST_ID, |
||
| 57 | InputArgument::REQUIRED, |
||
| 58 | 'The ID of the pull request' |
||
| 59 | ), |
||
| 60 | new InputOption( |
||
| 61 | self::OPTION_TOKEN_OR_USERNAME, |
||
| 62 | ['t', 'u'], |
||
| 63 | InputOption::VALUE_REQUIRED, |
||
| 64 | 'The token or username to authenticate to the API with. Assumed to be token without password' |
||
| 65 | ), |
||
| 66 | new InputOption( |
||
| 67 | self::OPTION_PASSWORD, |
||
| 68 | 'p', |
||
| 69 | InputOption::VALUE_OPTIONAL, |
||
| 70 | 'The password to authenticate to the API with' |
||
| 71 | ), |
||
| 72 | ] |
||
| 73 | ) |
||
| 74 | ); |
||
| 75 | } |
||
| 76 | |||
| 112 |
This check looks for multiple assignments in successive lines of code. It will report an issue if the operators are not in a straight line.
To visualize
will produce issues in the first and second line, while this second example
will produce no issues.