Compact or Verbose Codestyle?

I don't concern myself with the number of lines (compact vs verbose).

Code must first be readable (by a new programmer, at 5pm on Friday, operating on four or less hours of sleep). You're going to run into trouble with anything else.

I've never encountered code that was too readable. But I have encountered plenty of puzzle/mystery/deceptive/spaghetti code.

I'm not a js developer, but I would use this middle ground (hoping it actually does the same thing) :

const get = (store, key) => {
    if (!Reflect.has(window[store], key)) {
        throw new Error(`Key "${key}" not found in window.${store}.`);
    }

    return JSON.parse(window[store][key])
};

I guess you would have want to use the ternary operator to make it more readable, instead of adding the || and && which are harder to understand: the ternary operator accepts a nicer and more predictable form of (value, ifTrue, ifFalse) instead of constructing it on your own with boolean operator magic

const get = (store, key) =>
  Reflect.has(window[store], key)
    ? JSON.parse(window[store][key])
    : new Error(`Key ${key} not found`)

I guess this is readable enough, but I'll probably use the "verbose" one (it really depends on the project standards): I like early returns, or "guard" clauses - can help debugging by understanding that you can stop evaluating the function in your head 😺

There are two completely independent idioms that make the 2nd example more verbose:

1. The use of if instead of boolean operators for conditions. I tend to use if as the default and sometimes refactor when I think that the code is more readable when using a boolean operator. I also know some people who always use if and consider the other variant as a misuse of boolean operators.

2. The use of intermediate constants for function returns instead of function chaining. This can be useful for two reasons: You can use meaningful names for these constants that provide additional information about what is happening and thus make the code more readable. In this example, I would say that the names jsonStr and especially dataObj do not provide much useful information. Another reason not to chain function calls is to make debugging easier.

I personally have a certain bias towards compactness and like the 1st example slightly more. In real code, the optimum is probably somewhere in between.

If forced to choose between the two, definitely "Verbose". I think it's TOO verbose though. I don't see why it needs all the intermediate variables after the early throw if statement.

I can almost guarantee that coming back to either of these examples 6 months after writing it, it will take less time to understand the explicit if statement and behavior in the "Verbose" example. Even if it only takes an extra few seconds to read the "Compact" example, that still adds up if you're reading through an entire code path and trying to understand it.

They appear to do not have the same behaviour?

Between those two choices, I'd definitely go for the second one: the time you save writing less characters will not make up the hours you might lose in bug hunting.

As others have already pointed out though, there are two approaches used here:

• The guard clause (the if statement) helps separate the concerns within the method, since validation and data retrieval are indeed separate concerns.
• Extracting intermediate variables can be really helpful when the variable names communicate their (domain) purpose. In the example, that's however not really the case.

I think the important thing to keep in mind is that while the first example is much shorter (in amount of characters), it has exactly the same logic and the second example. That's to say: it's much more dense, meaning that you have to mentally de-compress it when you want to make changes to it. That doesn't help maintainability, and might even slow you (or your colleagues) down in the long run.

Always program as if the next person, who will be supporting your software is a psychopath, who knows where you live.

When your code isn't easy to understand and obvious from first sight - it's cr*p

Two, hands down, with dataObj variable inlined and the method called something more descriptive. One is too obscure. I've been doing JavaScript development for over a decade and every time I have to look up the bizarre JavaScript && and || return logic

I don't believe it length of the code matters as much now as long as the algorithm is correct and the code is readable. There are plenty of optimizers and minifiers that a project can use to reduce production code.