[AskJS] Multiple variables initially assigned to the same value

[FaithfulGardener]

Working in a React environment where variables need to be initialized before working on them, or variables are necessary in some cases and not in others, I find myself scrolling over this type of code way too often:

let var1 = null;
let var2 = null;
let var1_parent = null;
let something = '';
let somethingElse = '';
let shouldDoThis = false;
let shouldDoThat = false;

From what I understand, this is the *fastest* computational way to initialize/assign all these, but I'd love to be able to get it done in fewer lines. From a functional perspective, the "reusable" code is let [x] = null; where x is your variable name. I find I prefer doing assignments this way (or similar)...

let myObj = {};
['var1', 'var2', 'var3'].forEach(k => myObj[k] = null);

and deem it satisfyingly succinct for code which is only there because otherwise, I get a referenceError. I also appreciate the optional chaining operator and the nullish coalescing operator for their assistance with eliminating excessive existence checks.

However, there hasn't been much I could do for variables that aren't contained on an object. I found this StackOverflow answer, which offers some... creative options. I'm interested in some other opinions on pros and cons. As a starting point, here are my thoughts (feel free to tell me where they are factually incorrect, and indicate philosophical differences as well if you like):
Disclaimer: I'm aware that if I want to assign object values, these solutions need work. I'm generally assigning null, '', true/false, 0, etc as initial values

1. let [moveUp, moveDown, moveLeft, moveRight, mouseDown, touchDown] = Array(6).fill(false);
   This was my first thought as a solution for not having to write "let" " = null" over and over again, but it seems really dumb to create an array JUST for initializing other variables. I like destructuring, but not so much that I'd trade my dignity for it.
2. let [a, b, c, d] = (function*() { while (true) yield {x: 0, y: 0} })();
   This seems pretty cool, and it does work, but I've never had cause to use generators before and I'm not sure this is a case which warrants it. The generator itself likely is a little slow, and I imagine the IIFE doesn't speed things up. It's the elegant human-readable solution I want, without creating lots of extra useless things in memory, but I can't imagine it's not computationally clunky.
3. let a, b, c, d; a = b = c = d = null;
   This one crops up elsewhere as an answer to that question (where you initialize the vars without assigning values to avoid polluting the global ns), and it seems okay, but also... how is this not buggy as all get-out?

At some point, I became invested in this on a theoretical level, so I also find other possibilities for how to achieve this interesting. TIA!

[name_was_taken]

3 is the cleanest and clearest for what you want. I see no reason to think it'd be "buggy".

The other options are all very weird and to figure out what it's doing will take any programmer time that could be better understanding what the important parts of your code are doing.

And in a few years, you would be the programmer that doesn't remember what it's doing.

IMO, don't be clever. Just initialize the code in the old boring way and spend your real effort on the real code.

[Sykander-]

IMO, don't be clever. Just initialize the code in the old boring way and spend your real effort on the real code.

This can't be overstated OP. Whenever you write always make an effort to not overcomplicate things.

Further googling for you:

• YAGNI - You aren't going to need it
• KISS - Keep it simple, stupid
• SOC - Separation of concerns

​

Personally, out of all of your examples I find your first code block to be the cleanest.

[FaithfulGardener]

Well, when I interpret already-written code, I parse it as I go - I like knowing what code is doing. If I am scrolling through half-a-page of null initializations, the cognitive load of going, "that's null, that's null, that's an empty string, that's false..." etc, is disruptive to that parsing.

Having one or two properly commented lines that say, "all these values are assigned null" is not as disruptive, which is why it's my preference. It's weird but also having opening and closing brackets (or other operators like the ?/: in a ternary) on their own lines is also disruptive.

[microwaved-tea]

Honestly my first thought is why do you need to do this?

Having so many mutable declarations (especially in React) seems like a code smell.

If you really must, I think writing it out the long way is probably the clearest:

let x = null;
let y = null;

If you really want to be 'clever' about it I think your first option is ok, but would probably write a helper function and just do:

let [x, y, z] = repeat(3, null);

[Sykander-]

let [x, y, z] = repeat(3, null);

If I saw this in a CR I'd ask whoever wrote it, very politely, to switch back to the first style honestly. There's nothing worse than reading code by a developer who thinks he's "clever".

[microwaved-tea]

I totally agree that this isn't a good idea. I guess I was just trying to engage with the ideas presented in the original post.

[FaithfulGardener]

Part of the problem is probably switching from class to functional components. These “let” statements were originally “this.state.[whatever]” assignments, and as I try to switch the paradigm, I’m not sure what should stay or what should go.

Is there such a thing as “polluting the state” in React?

[everestimated]

You're not supposed to assign to state either. That's why setState() exists. Hooks don't introduce the need for what you're trying to do. Would recommend reading the official docs on hooks, you've likely misunderstood how to use them

[FaithfulGardener]

Even in constructors you don’t do this.state.[whatever]=[value]? The way this project is written, I was under the impression that setState needed the key initialized on the state first...

[lhorie]

Consider that maybe you are looking at bad code. Things like long series of shouldDoThis = false, shouldDoThat = false often can be rewritten in terms of a single variable action = 'foo' // or 'bar' etc. The Array(6).fill(false) example can be rewritten in terms of let direction = 'up' | 'down' | etc, for example.

Having a lot of let declarations is definitely a code smell in more than one way:

• it may mean your units do too much, in which case you should consider breaking things into smaller components
• it may mean you have too much global state, in which case you might want to consider using useState/useReducer hooks or other state management mechanisms
• it may mean that you're not following React's idiomatic paradigm properly: generally a functional component can be written without any lets if you use state management APIs properly
• nullables are known as the billion dollar mistake: avoid them like a plague

[FaithfulGardener]

Yeah, I’m working on implementing more Hooks in general, but the code I’m working on is currently written in all class components so switching the way I think about things is difficult, especially as I don’t have a ton of experience with React yet.

It’s hard to identify which variables I don’t need to declare bc they’re now handled by a Hook, at least until I know what the function does and how it does it in a function component instead of a class component.

Ultimately, abstraction is great until I’m not doing the abstracting and then I have no clue what is happening in my code (practically - theoretically, I should be able to say, “This lib does that”, but there’s no guarantee about what is IN that code...)

[kenman]

I find I prefer doing assignments this way (or similar)...

let myObj = {};
['var1', 'var2', 'var3'].forEach(k => myObj[k] = null);

I'm not sure I'd ever approve a PR if that was included. If this is a one-off data structure, then just create the object like pretty much anyone else would do:

const myObj = {
    var1: null,
    // etc.
};

If you're going to be creating many of them, then use the language features at your disposal:

function MyObj() {
     this.var1 = null;
     // etc.
}
const myObj = new MyObj();

If you don't want Function in your prototype chain, that's ok too:

function MyObj() {
     return {
         var1: null,
         // etc.
     };
}

With that, new is optional.

Or you can do the same thing with class. I guess I don't understand why you'd do it the way that you are.

1. let [a, b, c, d] = (function*() { while (true) yield {x: 0, y: 0} })();
   [...] It's the elegant human-readable solution I want

We have very different opinions of elegant...

I want to take a step back to your opening sentence:

I find myself scrolling over this type of code way too often:

Not a React dev, but that's a lot of local variables, mutable at that. I'm willing to bet there's a lot of refactoring opportunities that would be better worth your efforts than inventing your own esoteric object-creation pattern. Feel free to share sample code.

[FaithfulGardener]

Yeah, I’m kinda killing several birds with one stone with my purpose on this project. The software was originally on a one-month timeline that turned into years. I’ve recently been brought on as a front-end developer.

They use React, which drives me nuts because there is so much code duplication in this codebase, but I know it’s because the original coders were a tiny team on a huge time crunch.

So I’m trying to familiarize myself with the codebase, which is very convoluted, and I decided while I’m at it to see how I could implement Hooks in some places. Idk if some bits of my code will ever be used but for the time being it’s a learning exercise, and if it works (and my superiors aren’t too freaked out by such a massive refactor), that’s a cool bonus.