13
ankit05
6y

One of my TL said to me during code review that place a break statement after return statement in switch case.

Being with a bar leader can certainly degrade your code quality.

Comments
  • 3
    Not only that it wouldn't compile in java [I think] cuz of dead code, it's also not the greatest idea to return in switch. You should use as little exit points from the fn as possible.
  • 0
    @netikras tell this to my fucking asshole TL... bdw it's js so it was compiled though being a dead code😂
  • 1
    @irene I'm not talking about failfast returns nor about simple algorithms, like a 3-line value lookup code. switch-case does not seem to be the right fit for a failfast nor a lookup.

    Functions that have multiple exit points are a perfect way to make a spaghetti. They are harder to read, harder to maintain.
  • 1
    @irene It's the first time I hear (read) MISRA. Why doesn't it allow failfasts?

    failfast switch you say...? I already imagine something like:

    public void sell(Long itemId, Customer.Type type, Long customerId) {
    switch (type) {
    case GOOD:
    return;
    case BAD:
    case SOMEWHAT_BAD:
    if (getCustomer(customerId).getBadness() > 700) {
    if (reevaluateBadness(customerId) > 700) {
    return;
    }

    }
    break;
    case IN_DEBT:
    sendEmailAboutDebt(customerId);
    if (getDebtNotificationsSentCount(customerId) > 20) {
    return;
    }
    break;
    }

    Customer cust = getCustomer(customerId);
    Item item = getItem(itemId);

    if (canSell(item, customer)) {
    doSell(item, customer);
    }
    }

    How easy is it to see all the function exit points?

    Thank you dR for messed up formatting...
  • 0
    @irene oh.. that's nice!
  • 1
    You can never judge the best use case of any control without knowing the use case. In our case, The product is designed in such a way as the user event is being captured which is then further dealt in java after return.
  • 0
    @ankit05 That's incorrect. Labeled breaks and GOTOs are considered a bad practice in general, no matter what's the use case. This proves that one actually CAN judge controls w/o knowing your use case.

    In OOP switch-case is also something to be avoided though not considered rudimental yet.
  • 0
    @netikras okay buddy... You can judge.. be happy 😂
  • 0
    @irene "goto"s then?
  • 0
    @hash-table exactly.. bdw it's an event capturing method. So we have to return the control in every case to the main file as soon as the event is captured. 😉
Add Comment