CODEWITHSUNDEEP
javascript
larryq
larryq

Reputation: 16309

Is there a techincal issue with initializing a javascript variable to an empty string instead of null?

I'm working with an API call using axios and getting back some JSON in a response. I have a variable that will hold the result of one of the JSON object's values, in this case a string:

let first_name = "";
//later on..
first_name = response.data.firstName;

I had my hand slapped because I had initialized first_name to an empty string instead of null and I'm not sure why-- the person doing the code review muttered something about best practices and didn't really answer me.

My question-- if I'm checking for an empty string instead of null when using first_name later on, does it matter what I initialized it to? Is there a javascript best practice or optimization I'm missing out on by setting the variable to an empty string?

[edit]

Some good discussion in the comments about how I'm using first_name later on in the code. Let me elaborate.

I don't want to do a code dump, so let me put it this way, after first_name has been assigned I check to make sure it's neither an empty string or null before using it. What I'm interested in here is whether what I did is wrong or inefficient in javascript terms, or 'worse' than assigning it as a null. I assigned it as a string as a mnemonic that it should be a string value if all goes well.

Upvotes: 1

Views: 809

Answers (4)

t.niese
t.niese

Reputation: 40862

Initializing first_name with a value makes only sense if there is a possibility that first_name = response.data.firstName won't be executed and code after that reads from first_name:

let first_name;

if( ... ) {
   first_name = response.data.firstName;
}

// ...

doSomething(first_name)

or

let first_name;

try {
   // some code
   first_name = response.data.firstName;
} catch(err) {
}

// ...

doSomething(first_name)

Because then you could ensure some default values.

But if there is nothing in between let first_name; and first_name = response.data.firstName; then initializing of first_name does not make sense, and declaring it that early does not make sense either.

So it should be:

let first_name = response.data.firstName;
// ...
doSomething(first_name)

Moving all declaration to the beginning of the function is a relic from the time where let and const were not available, because the engine/compiler would not warn you about:

function foo() {
   console.log(bar)

   // ...

   var bar = 2; 
}

Upvotes: 0

Shraddha Goel
Shraddha Goel

Reputation: 897

I do understand that javascript supports all these as a falsy values

  • false
  • 0 (zero)
  • “” (empty string)
  • null
  • undefined
  • NaN (Not A Number)

It directly indicates that null and empty string both are false. All is depending on the use case. According to your use case, it is okay to use an empty string. But still, I suggest using null for these better improvements.

  • Null is a best practice to show there is no data available.
  • An empty string indicates empty data is provided while null indicates no data is provided.
  • Empty data can end up you to produce buggy code by providing access to the class members while data returned as null comes under the null exception and prevent you from the buggy code.

Upvotes: 0

Zeta
Zeta

Reputation: 105905

Is there a technical issue with initializing a JavaScript variable to an empty string instead of null?

That depends on the context, but there is no immediate technical issue. From a pure technical perspective, it doesn't matter whether we check first_name === null, first_name === "", first_name === undefined or just !first_name.

Note that all of this is very specific to JavaScript, as many other languages either don't have Null or use a completely other model to indicate the absence of values.

null versus string

Let us analyse the issue a little bit further to understand the reasoning of your reviewer.

null is not a string

In the end first_name is a result of some computation that returns a string. If that string can be the empty string "", it's reasonable to use null, as null !== "". We can check the absence of a valid value without additional first_name_set flags or similar.

If we use null, then we never pool our initial value from the domain of valid values, which can be a boon in debugging, error handling and sanity checks.

"" might not ever be valid

If, however, first_name will never be the empty string, the empty string might be a valid candidate for our invalid data.

Best practices must be explained

But this explanation for null is something one can up with. The reasoning of your reviewer on the other hand is in their mindset. If it is best practice according to them, it might be "best practice" throughout the company. That doesn't necessarily mean that it's also best practice in the real world, as some weird misconceptions can have a long tradition in companies with a lot of self-taught programmers. Your best practice as a reviewed would be to question their reasoning.

A good code review improves the reviewed code, a better code review teaches better practices, but the best code reviews improve the overall code base and teach both sides.

Remark on initialization

That being said both variants employ additional pressure on the developer: we're forced to check whether our value is valid. A better solution (if possible) is to get rid of the invalid initialization and only initialize with a correct value. async and await can enable us to do so in callback situations.

Upvotes: 7

Bhojendra Rauniyar
Bhojendra Rauniyar

Reputation: 85575

I think your reviewer is thinking of:

  • Using null states no data is available.
  • Using empty string states data is available (returned from api).

I also agree with that using null will be best practice in that sense.

Upvotes: 4

Related Questions