• The exception does not get tested.

  • It would be helpful to inform the user on the appropriate values to populate the dictionary with in the instructions. Took me a while to find this out.

  • While this is a good learning Kata for C#, throwing an InvalidOperationException for a missing key is not best practice.

    From Microsoft C# docs:

    InvalidOperationException is used in cases when the failure to invoke a method is caused by reasons other than invalid arguments. Typically, it is thrown when the state of an object cannot support the method call.

    The hint in the starter code suggests using a dictionary as the underlying data structure. A dictionary would throw a "KeyNotFoundException" if the key isn't null and dictionary is not referenced with the TryGetValue method.

    I'd suggest changing that test case to accept KeyNotFoundException as well.

  • As many top 'coding craftsman' already said, when your variable needs an explaining comment you did something wrong

  • It is beyond me how a (supposed) 1 dan moderator could approve such an obviously problematic Kata

    Because he's a spammer, and quite a possibly a cheater (as you said). Not surprising that his "moderation" is a joke as well.

  • Well, the Kata author did admit right in the Kata description that the tests allow a solution keeping the original switch/case to pass ;)

    NOTE: Yes the tests will pass by doing nothing and leaving the switch...case construct present, but the idea of this kata is to give you an insight into removing switch statements from your code and looking for alternative constructs, in this case, a dictionary.

    It is beyond me how a (supposed) 1 dan moderator could approve such an obviously problematic Kata :/

    • public Customer Customer returns a reference to the Customer if one is present or throws an InvalidOperationException with the message of "No customer present. Please consider calling 'HasCustomer' to check for presence first" if not.

    The exception message is not tested.

  • The kata's proposed design for such a Option type is nonsense:

    • Why inherit from IEnumerable? What IEnumerable means is that this Optional type can have 0 to many values. So the problem is not resolved at all, in fact it's even worse (it was 0 or 1 before).
    • Similarly, why IEnumerable<Customer>? Why not make it a generic type? Why is it named Kata and not something more meaningful (like IMaybe)?
    • The interface for obtaining the value is also nonsense because it does not distinguish between the concept of plain value and a collection of values. Why does it provide both .Customer and .GetEnumerator()? It cannot be both a plain value or a collection of values at the same time: if it's a plain value you need to lift it to get a collection, if it's a collection you need to Find/First from it to get a plain value.
    • As mentioned below, the standard way to handle this in C# is null-conditional operators.
  • Initial code namespace should be MaybeKata, not MaybeKata.Incomplete.

  • Demonstrating Option type in C# is a poor choice because it's not the C# standard practice: the standard practice is to use the null-conditional operators instead.

    The kata should be re-written in a language where such type exists and are used extensively as standard practice.

  • In functional programs these structures are often called "Options", in other languages they are often called "Maybe"s.

    I think it's the opposite. At least in Haskell it's called Maybe, while in Scala it's called Option and in Java it's called Optional.

  • As the kata currently stands it's completely pointless because the tests are not leveraging the benefit of the refactoring.

    The point of turning Status into a class is that anyone can add new Statuses from their side and the code will still work automatically with no changes to Kata class itself required. The tests or the description did not demonstrate any of this. So whatever learning value this kata might have it's whooshed from us; instead what we get is "refactor this way because I said so".

    Also, why check if there's a _status field? It's also pointless.

  • Where are the random tests?

  • Loading more items...