Passed
Pull Request — master (#202)
by Jan
03:27
created

oval_graph.command_line.arf_to_json()   A

Complexity

Conditions 2

Size

Total Lines 6
Code Lines 6

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 0
CRAP Score 6

Importance

Changes 0
Metric Value
eloc 6
dl 0
loc 6
ccs 0
cts 6
cp 0
rs 10
c 0
b 0
f 0
cc 2
nop 1
crap 6
1
"""
2
    This file contains entry points for commands
3
"""
4
5
import traceback
6
7
from .command_line_client.arf_to_html import ArfToHtml
8
from .command_line_client.arf_to_json import ArfToJson
9
from .command_line_client.json_to_html import JsonToHtml
10
11
CRED = '\033[91m'
12
CEND = '\033[0m'
13
14
15
def print_detail_traceback_if_verbose(args):
0 ignored issues
show
Comprehensibility Bug introduced by
args is re-defining a name which is already available in the outer-scope (previously defined on line 72).

It is generally a bad practice to shadow variables from the outer-scope. In most cases, this is done unintentionally and might lead to unexpected behavior:

param = 5

class Foo:
    def __init__(self, param):   # "param" would be flagged here
        self.param = param
Loading history...
16
    if any(arg in args for arg in ("-v", "--verbose")):
17
        traceback.print_exc()
18
19
20
def arf_to_graph(args=None):
0 ignored issues
show
Comprehensibility Bug introduced by
args is re-defining a name which is already available in the outer-scope (previously defined on line 72).

It is generally a bad practice to shadow variables from the outer-scope. In most cases, this is done unintentionally and might lead to unexpected behavior:

param = 5

class Foo:
    def __init__(self, param):   # "param" would be flagged here
        self.param = param
Loading history...
21
    try:
22
        main(ArfToHtml(args))
23
    except Exception as error:
0 ignored issues
show
Best Practice introduced by
Catching very general exceptions such as Exception is usually not recommended.

Generally, you would want to handle very specific errors in the exception handler. This ensure that you do not hide other types of errors which should be fixed.

So, unless you specifically plan to handle any error, consider adding a more specific exception.

Loading history...
24
        print_detail_traceback_if_verbose(args)
25
        print((CRED + 'Error: {}' + CEND).format(error))
26
27
28
def arf_to_json(args=None):
0 ignored issues
show
Comprehensibility Bug introduced by
args is re-defining a name which is already available in the outer-scope (previously defined on line 72).

It is generally a bad practice to shadow variables from the outer-scope. In most cases, this is done unintentionally and might lead to unexpected behavior:

param = 5

class Foo:
    def __init__(self, param):   # "param" would be flagged here
        self.param = param
Loading history...
29
    try:
30
        main(ArfToJson(args))
31
    except Exception as error:
0 ignored issues
show
Best Practice introduced by
Catching very general exceptions such as Exception is usually not recommended.

Generally, you would want to handle very specific errors in the exception handler. This ensure that you do not hide other types of errors which should be fixed.

So, unless you specifically plan to handle any error, consider adding a more specific exception.

Loading history...
32
        print_detail_traceback_if_verbose(args)
33
        print((CRED + 'Error: {}' + CEND).format(error))
34
35
36
def json_to_graph(args=None):
0 ignored issues
show
Comprehensibility Bug introduced by
args is re-defining a name which is already available in the outer-scope (previously defined on line 72).

It is generally a bad practice to shadow variables from the outer-scope. In most cases, this is done unintentionally and might lead to unexpected behavior:

param = 5

class Foo:
    def __init__(self, param):   # "param" would be flagged here
        self.param = param
Loading history...
37
    try:
38
        main(JsonToHtml(args))
39
    except Exception as error:
0 ignored issues
show
Best Practice introduced by
Catching very general exceptions such as Exception is usually not recommended.

Generally, you would want to handle very specific errors in the exception handler. This ensure that you do not hide other types of errors which should be fixed.

So, unless you specifically plan to handle any error, consider adding a more specific exception.

Loading history...
40
        print_detail_traceback_if_verbose(args)
41
        print((CRED + 'Error: {}' + CEND).format(error))
42
43
44
def main(client):
45
    rules = client.search_rules_id()
46
    if len(rules) > 1:
47
        answers = client.run_gui_and_return_answers()
48
        if answers is not None:
49
            client.prepare_data(answers)
50
    else:
51
        client.prepare_data({'rules': [rules[0]]})
52
53
54
if __name__ == '__main__':
55
    import argparse
56
57
    parser = argparse.ArgumentParser()
58
    subparsers = parser.add_subparsers()
59
60
    parser_arf_to_graph = subparsers.add_parser(
61
        'arf-to-graph', help='Executes the arf-to-graph command.')
62
    parser_arf_to_graph.set_defaults(command=arf_to_graph)
63
64
    parser_arf_to_json = subparsers.add_parser(
65
        'arf-to-json', help='Executes the arf-to-json command.')
66
    parser_arf_to_json.set_defaults(command=arf_to_json)
67
68
    parser_json_to_graph = subparsers.add_parser(
69
        'json-to-graph', help='Executes the json-to-graph command.')
70
    parser_json_to_graph.set_defaults(command=json_to_graph)
71
72
    args, command_args = parser.parse_known_args()
73
    args.command(command_args)
74