0

I am implementing if/else statement, by using function "inCase" to make it more readable:

const size = 'small'

const equals = str1 => str2 => str2 === str1

const inCase = (obj) => (predicate) => (whenTrueFn) => (whenFalseFn) => {
    predicate(obj) ? whenTrueFn() : whenFalseFn()
}

const renderMobileNavBar = () => console.log("Rendering Mobile")
const renderDesktopNavBar = () => console.log("Rendering Desktop")

const otherwise = fn => () => fn()

inCase(size)(equals('small'))(renderMobileNavBar)(otherwise(renderDesktopNavBar))

But in this case "otherwise" function is completely unnecessary I could have called my function like this:

inCase(size)(equals('small'))(renderMobileNavBar)(renderDesktopNavBar)

It works the same, the only difference is in readability. So I wonder does it make sense to keep "otherwise" function just for readability?

9
  • Shouldn't responsive design render this question moot? Jun 20 at 18:56
  • Responsivness is just an example, I meant this more as a general question Jun 20 at 18:59
  • That's fair. Typically polymorphism is used in these cases, though. Jun 20 at 19:01
  • 10
    Sorry if this I am missing out on the latest coding fad, but what on Earth is the point of doing all this delegate stuff when all you need is an if construct?
    – John Wu
    Jun 20 at 19:07
  • 5
    My two cents: While this is clever and interesting, don't take the recommendation to make the code more readable so literally. It's not fundamentally about making it read like an English-language sentence, it's about communicating intent. If you think of code as something written to be read by people later on, then consider your readership: your fellow devs don't need you to make a simple if/else statement more readable - they can handle that. What's more valuable to them is to make the intent of the code something that can be readily read from the screen. 1/2 Jun 20 at 19:38

2 Answers 2

14

We do a lot of things in programming just for the sake of readability - like giving variables meaningful names (instead of just naming them a, b, c, d, ...).

Or specificially conditionals - there is a good reason why many languages require an explicit else statement for the block to be executed or evaluated in the related case. However, there are also programming languages like Lisp where brevity is preferred over explicitness and the "else" part of the conditional does not require any extra keyword. So in the end, it is a matter of taste.

However, I think it is a really huge code smell when one starts to reimplement existing language constructs with alternate keywords for no apparent benefit. Any half-experienced Javascript programmer will immediately understand what

 (size ==='small') ? renderMobileNavBar() : renderDesktopNavBar()

means. But whoever reads

 inCase(size)(equals('small'))(renderMobileNavBar)(renderDesktopNavBar)

will probably wonder if there is special reason why a simple condition like the former is implemented in this overcomplicated fashion.

7
  • 2
    Unless they know: Job security. ;-) Jun 20 at 19:49
  • I see, thank you for your opinion, I got an idea from Ramda library where they have "when" function which is used when u have single "if" statement, so I wondered how if/else would look like. Jun 20 at 19:52
  • 3
    Often a slightly better way to do something common (like that When construct) is not so good after all just because it will likely be new to the reader and thus will snoop some of his brain power. This is called disrespecting "prior art". If-then is prior art, everyone is familiar with it. Count instead of NumberOfItems is prior art. Jun 20 at 19:58
  • Yeah, I thought about that too, it does make sense. Jun 20 at 20:12
  • @DjordjeVuckovic: you need to be careful with library code. Sometimes they reinvent the wheel simply because they can reduce the file size by a few bytes. That might be the reason the Ramda library has a when function instead of an if statement. It is a micro optimization for a specific used case — or it might exist to facilitate asynchronous programming. Jun 20 at 21:48
7

Possibly yes, but in this case no —- because your extra functions don’t make your code more readable.

 const renderNavBar = (size ==='small') ? renderMobileNavBar : renderDesktopNavBar;
/* whatever*/
renderNavBar();

Could make the code more readable, if there were some reason to repeat the condition in multiple places (or even just to have shorter lines).

But while this

inCase(size)(equals('small'))(renderMobileNavBar)(otherwise(renderDesktopNavBar))

reads as a simple english sentence, it screams unknown and hidden activity to a javascript developer (and screams even more loudly to a backend dev that has to work a frontend ticket).

If I had a ticket where the error seems to be in that area, I’m going to stop reading the surrounding code looking for the problem, and review those several times to make sure I’m not misunderstanding it and it’s not the source of the problem. That makes it the opposite of readability.

A simple ternary or even an if/else condition are unambiguous, I deal with them dozens or even hundreds of times a day. inCase, equals, otherwise? Never saw them before, and who would be redefining simple language constructs for no good reason?

1
  • I agree with this answer (+1). To be fair, the OP mentioned they were taking their ideas from Ramda, which is a foundation lib which intentionally uses a different style than what Javascript provides out-of-the-box.
    – Doc Brown
    Jun 21 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.