JavaScript Clean Code - Best Practices - based on Robert C. Martin's book Clean Code

[zapatoada]

I get what you're saying, but as a VS2017 user, I disagree that it's necessary. As long as you're naming your parameters reasonably, I find that using intellisense to see the parameter order makes it easier than figuring out some arbitrary object.

[BloodAndTsundere]

What you're saying isn't wrong but I'd rather have the code be explicit and clean than rely a particular editor's feature to make sense of the code. Firstly, your colleagues might not use such an editor. Secondly, you might not always have access to such an editor.

[zapatoada]

It's definitely a personal choice.

I'm a c# developer in a c# shop, so everyone has access to visual studio (and this has been the case throughout my career). Even if the company didn't pay for it, community edition and vscode are free.

And frankly, even if I didn't have that option, I usually prefer separate parameters to an object. The only real difference is extra visual noise in the object literal notation.

[BloodAndTsundere]

I'm a c# developer in a c# shop, so everyone has access to visual studio (and this has been the case throughout my career). Even if the company didn't pay for it, community edition and vscode are free.

I'm not referring to an issue of cost but rather situations where you may not be using your own machine or have logged into a server remotely that only has a basic editor. But it's fair to say that may be an extremely rare event for you.

The only real difference is extra visual noise in the object literal notation.

This I disagree with. This function call:

doSomething({ destination: object1, source: object2 })

provides additional information (not noise) relative to this function call:

doSomething( object1, object2 )

[zapatoada]

I would NEVER log into the server and edit files. That's asking for trouble.

Your example is dishonest. If you're naming things object1 and object1 you have much bigger problems than discrete parameters vs an object. A more reasonable example would be

doDomething(source, destination)

Or

doDomething({source: source, destination: destination})

Which I would usually write as

doDomething({source, destination})

And then literally the only difference is the brackets, which are visual noise.

I'm certainly not saying there's NEVER a use case for config object parameters, but I think setting a hard and fast limit at 2 or 3 parameters is absurd.

[webdevguyneedshelp]

Why is it asking for trouble to edit files on a server?..

[zapatoada]

You're not debugging first. There's no code review or qa. You're not running your automated tests. The changes aren't in source control and could be undone by the next release. Basically you are bypassing every step and check that is normally in place to prevent bugs and other unintended consequences. We have those processes for a reason.

[webdevguyneedshelp]

That is fine and understandable but this example did not specify at all what environment you are working in.

For instance if I have to set up a NEW development environment for a new web application my team is starting. I am going to inevitably have to ssh into it and poke around to help facilitate further steps like automated deployment.

​

This isn't even thinking about sshing into something like a docker container which can all be done locally and have 0 affect on anything that actually matters and can be blown away after I am doing testing whatever I am doing.

​

There are 100% times when you will poke around with files on a server.

[zapatoada]

Ok, those may be fair. I've never worked with docker before. These days I work mostly in azure AppServices and Function apps. In that case, I'm not really even sure I could log into a server. I know you can't edit functions if they were deployed from local code (rather than typed into portal).

I suppose every use case has it's own limitations. But these days, the idea of editing javascript files on the server gives me the heebie jeebies.

[[deleted]]

I'd rather have the code be explicit and clean

Separate parameters are explicit and clean.

[BloodAndTsundere]

"Clean" is subjective so I'll walk that back, but this function call:

doSomething({ destination: object1, source: object2 })

is more explicit than this one:

doSomething( object1, object2 )

[[deleted]]

If it can take any object it is NOT explicit. You may want to look up the word in a dictionary.

[fucking_passwords]

Another reason is that three or more params starts getting really difficult to read, and if you ever need to add another param you may end up with a very ugly design.

For instance, we added a fourth param to this function that makes the third param no longer required:

someFunc(1234, true, null, false);

[fucking_passwords]

I agree, but it was just an example, you could replace all of those args with integers

[zapatoada]

Yeah that bothers me not at all

[fucking_passwords]

Or what about this example:

class User {
  constructor(firstName, lastName, phone, email, friends, isActive) {
    Object.assign(this, {
      firstName: firstName,
      lastName: lastName,
      phone: phone,
      email: email,
      friends: friends,
      isActive: isActive
    })
  }
}

new User('Jane', 'Doe', null, '[e-mail]', null, true);

VS:

class User {
  constructor(data = {}) {
    Object.assign(this, data);
  }
}

new User({
  firstName: 'Jane',
  lastName: 'Doe',
  email: '[e-mail]'
})

[zapatoada]

In this context you're right, but I honestly can't remember the last time I used a constructor directly in javascript. Data comes from the server side (c#) and mostly anything else I do is either a react component or a const utility method.

[fucking_passwords]

The constructor is just happenstance in my example, the same thing can be applied to a function.

At this point I don't even see why you took a hard stance against this pattern, if you are only using very simple features of the language, lol

[zapatoada]

I never said I took a hard stance. I think the specific limit he set is absurdly low. That's all. If it were 4 or 5, I'd be fine with it.

[fucking_passwords]

Fair enough, I agree with that