evm: Remove dubious booleans in evm

[acolytec3]

Following on #2030, I noticed the linter complaining about some implicit boolean truthiness being checked in evm.ts so trying to come up with better typing to satisfy the new explicit boolean linter rule and also remove the isTruthy/isFalsy methods @gabrocheleau introduced for us to use as a fallback. I'm on the fence about whether I like the "improvements." Since alot of our booleans were previously using the existence of an object in a check as below:

if (someObject.Property) {
// do something
}

or

if (!someObjectOrVariable) {
/// do something
}

we basically have to check if something is undefined or not, and according to multiple stackOverflow questions, the only correct way to do this is to make our code look like this:

if (typeof someObject.Property !== 'undefined') {
// do something
}
// or
if (typeof someOjbectOrVariable === 'undefined`) {
// do something
}

What do y'all think?

[codecov]

Codecov Report

Merging #2055 (d429ac7) into master (2dd63b9) will decrease coverage by 0.04%.
The diff coverage is 55.55%.

Flag	Coverage Δ
block	84.01% <ø> (ø)
blockchain	80.10% <ø> (ø)
client	78.37% <ø> (ø)
common	94.90% <ø> (ø)
devp2p	82.60% <ø> (-0.13%)	⬇️
ethash	90.81% <ø> (ø)
evm	40.97% <55.55%> (ø)
statemanager	84.55% <ø> (ø)
trie	80.84% <ø> (-0.49%)	⬇️
tx	92.18% <ø> (ø)
util	87.22% <ø> (ø)
vm	78.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[jochem-brouwer]

We should not check if certain properties are the string "undefined", right, we should check if they are undefined. I see you used typeof in the commits though (so in that case we check undefined)?

Can you link this stack overflow question?

[acolytec3]

We should not check if certain properties are the string "undefined", right, we should check if they are undefined. I see you used typeof in the commits though (so in that case we check undefined)?

Can you link this stack overflow question?

There are numerous but this one makes the most sense to me. The argument for using typeof someVar === 'undefined' that we're explicitly testing the type of someVar(though I think that's arguably the same asif (someVar === undefined). This line Note: this last method is the only way to refer to an undeclared identifier without an early errorfrom the article is what motivated me to use thetypeof someVar...` pattern since it guards against trying to access an undefined and undeclared identifier that would result in an error if that identifier is referenced directly.

[holgerd77]

I guess using some code like typeof someObject.Property !== 'undefined' as a standard in our code base is a total no go, let's keep this a bit in discussion, eventually we need to adopt the linting rules again respectively evolve.

[acolytec3]

Okay, I'm gonna close for now so we don't clutter up our pull request log but we can revisit when needed.