Adding two examples: don't create useless classes and don't use if/else to "create" a switch

[felipevolpone]

I created more two examples:

• Don't create useless classes
• Don't use if/else to "create" a switch

I guess I put the files in the right place, but if is something wrong please tell me.

[adewes]

hey @felipevolpone , thanks for writing this! I will need a day to review it and do some editing, after that will merge them :) Really like the ideas for the articles, thanks so much for contributing!

[felipevolpone]

@adewes @programmdesign thank you!

[programmdesign]

@felipevolpone thanks for your patience :)

[vogelsgesang]

Sorry, that it took such a long time until we came back on this pull request.

Your ideas are really good. There are only two small things which we were not completely happy with:

• the head lines should be Anti-Pattern and Best practices instead of Example and Solutions
• The "Not using if/else to switch" solution actually changes the semantics of the code

With the proposed solution

def calculate_with_operator(operator, a, b):
    possible_operators = {
        '+': a+b,
        '-': a-b,
        '*': a*b,
        '/': a/b
    }

    return possible_operators[operator]

actually all 4 operators are evaluated but only the result of the requested operator is returned. In this example this only results in degraded performance, but if the actual actions had side effects this readability improvement would come at the cost of some possibly unintended semantic changes. In my opinion we should point this out more clearly.

We merged your pull request now but we should fix these two issues before putting the new version online at docs.quantifiedcode.org. @felipevolpone Do you want to fix them and make a pull request or should I fix them?

[felipevolpone]

Hey guys, I guess that I don't get the point. You want to change the code or document it better?