Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
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.
-
ankit05486y@netikras tell this to my fucking asshole TL... bdw it's js so it was compiled though being a dead code😂
-
@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. -
@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... -
ankit05486yYou 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.
-
@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. -
ankit05486y@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. 😉
Related Rants
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.
rant
depressed developer
fuck this shit