Completed
Push — master ( 68f30c...a95a96 )
by Christian
02:25
created

ActionAbstract::createProgressBar()   A

Complexity

Conditions 2
Paths 2

Size

Total Lines 11
Code Lines 6

Duplication

Lines 0
Ratio 0 %

Importance

Changes 0
Metric Value
dl 0
loc 11
rs 9.4285
c 0
b 0
f 0
nc 2
cc 2
eloc 6
nop 3
1
<?php
2
3
namespace uuf6429\ElderBrother\Action;
4
5
use Symfony\Component\Console\Helper\ProgressBar;
6
use Symfony\Component\Console\Input\InputInterface;
7
use Symfony\Component\Console\Output\NullOutput;
8
use Symfony\Component\Console\Output\OutputInterface;
9
10
abstract class ActionAbstract
11
{
12
    /**
13
     * Returns name of this action (possibly with some extra info).
14
     *
15
     * @return string
16
     */
17
    abstract public function getName();
18
19
    /**
20
     * Throws an exception when action is not supported (eg: missing lib etc).
21
     *
22
     * @throws \Exception
23
     */
24
    abstract public function checkSupport();
1 ignored issue
show
Documentation introduced by
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
25
26
    /**
27
     * Execute action for the given parameters.
28
     *
29
     * @param InputInterface  $input
30
     * @param OutputInterface $output
31
     */
32
    abstract public function execute(InputInterface $input, OutputInterface $output);
1 ignored issue
show
Documentation introduced by
For interfaces and abstract methods it is generally a good practice to add a @return annotation even if it is just @return void or @return null, so that implementors know what to do in the overridden method.

For interface and abstract methods, it is impossible to infer the return type from the immediate code. In these cases, it is generally advisible to explicitly annotate these methods with a @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
33
34
    /**
35
     * @param InputInterface  $input
36
     * @param OutputInterface $output
37
     * @param int             $steps
38
     *
39
     * @return ProgressBar
40
     */
41
    protected function createProgressBar(InputInterface $input, OutputInterface $output, $steps)
42
    {
43
        if ($input->hasOption('no-progress')) {
44
            $output = new NullOutput();
1 ignored issue
show
Coding Style introduced by
Consider using a different name than the parameter $output. This often makes code more readable.
Loading history...
45
        }
46
47
        $progress = new ProgressBar($output, $steps);
48
        $progress->setFormat(' %current%/%max% [%bar%] %percent:3s%% %memory:6s% %message%');
49
        //$progress->setRedrawFrequency(1);
0 ignored issues
show
Unused Code Comprehensibility introduced by
86% of this comment could be valid code. Did you maybe forget this after debugging?

Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it.

The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production.

This check looks for comments that seem to be mostly valid code and reports them.

Loading history...
50
        return $progress;
51
    }
52
}
53