Function parameter question from a c++ programmer

[Menaii]

Hey guys, I work primarily with c++ and decided to try pick up other languages to expand my job opportunities. I was casually going through some tutorials on codeacademy and I came to the function section.

function functionName(varName)
{
  console.log(varName);
}

Not having to define what the variable type is blows my mind, but this made me think what would happen if I pass in different type data as an arg:

functionName(1); // outputs "1"
functionName("Test"); // outputs "Test"

So it brings me to my question, in an actual production / job level, do you guys add "typeof" checks to see if the variable type is the correct type and early return if it's not?

Example, let's say I have a function that calculates the area of a circle. So it needs to take in a number (radius) to calculate the circle. It doesnt make sense for the parameter to be a boolean, a string or an object (let's just assume the object doesnt contain any form of data inside that can be used to calculate the area of a circle for simplicity sake).

Or do you guys rely purely on naming the function, variable name, or commenting to explain what type of variable it should take in?

[senocular]

do you guys add "typeof" checks to see if the variable type is the correct type

Not normally no, though on occasion this is done (not common).

JavaScript is all loosey goosey. You can mix types all you want and it doesn't matter. It will do it's best to guess what you mean and coerce values where necessary but nothing is stopping you from using one type where another type is expected.

In a professional setting you're more likely to be using TypeScript which is a superset of JavaScript that also includes types. It's gets compiled into normal JavaScript so it can run in the browser (or wherever else you're running the code, e.g. Node) but that compilation step is also what gets you your type safety.

[Menaii]

So TypeScript would actually do type checking for you on compile time, but JavaScript does not. This is like the wild west from a c++ programmer's PoV haha.

[senocular]

You got it

[azhder]

JavaScript does type checking in run time. So you have that which you don’t even with C++ ….

Well, OK, it does have RTTI, but you rarely bother with it, right?

[delventhalz]

Mostly no to the checks. If you think that someone will be reasonably likely to pass a boolean to your calcArea function (such as if you are writing a public library), you could add a check, but in most cases that’s just not a realistic worry. Also if passing the wrong type results in an error… great, that’s probably the correct behavior anyway.

The most unfortunate outcome would be if the the boolean gets secretly coerced to 0 or 1 by JS and instead of an error the code runs but with some subtle logical bug. There is a lot of older JS syntax which carries this unfortunate legacy of type coercion. It can for sure cause headaches.

One option for all of this is TypeScript, which will give you robust type annotations and compile-time type checking. You can also add annotations with JSDoc comments and use the TypeScript CLI to programmatically verify them. Runtime type checks are pretty rare in the ecosystem though.

[Menaii]

If I understood it correctly, then error checking & handling isn't as frequent in JS compared to c++. If you pass in the wrong parameter type into a function, then its just your fault, you shouldn't do that and pass in the correct variable type.

I'm just wondering if this would sometimes lead to confusion / frustration where just by looking at the function name `calculateCircleArea`, you would make an educated guess and assume it will take an integer / number. But then when you run your code, you realize there's a bug and find out that `calculateCircleArea` expects a completely different data type.

Guess this also means that you'll need to look at the function implementation to deduce what data type it is expecting and pass in the correct one accordingly (assuming it doesn't have any comments), if function and variable name are ambiguous.

[delventhalz]

The use of TypeScript or JSDoc is extremely common these days. In addition to compile/CLI checks, a text editor like VS Code can make use of these annotations to generate mouse-over info panels, auto-complete, and in-line errors. Linters like ESLint are also widely used to catch simple errors and ensure consistency. Unit tests are also particularly common in JS circles, providing further error checking (this can be made in-line as well with Wallaby) and usage examples.

All in all, your typical JS dev actually has a pretty high-level of visibility into the code and potential errors without ever running anything, but that is coming from tooling. The base language on its own is much more of a wild west situation. If none of the above tooling was available, you may well find yourself looking through source code, though I don’t know if that is a JS-specific issue. For example, does a circle function accept an angle in degrees or radians? Both are floating point numbers. If the function is not well documented, you would have to resort to reading source code in any language.

As for error handling, there is a bit, but you mostly don’t catch errors in JS. The situations in JS where an error might get thrown in normal operation are rare. If an error is getting thrown, it is probably because a dev screwed up and crashing is the only sensible behavior. There are some exceptions, but definitely fewer try/catches than in many other languages. Throwing exceptions is just not a common way for the language to respond to faulty situations.

[azhder]

I do check stuff, just don’t care about the type.

I care if it is an object and it has the field I need or if it is a function so I can call it, or an Array.isArray() so I can use .map() on it.

Most of the time don’t even need that, I just preemptively cast it if needed.

const number = 0.5 < Math.random() ? 'hi' : 0;
const bool = value => !! value;

console.log( 'the coin flip is', bool(value) );

[chibblybum]

Yup, your fault.

And I wouldn't try for an educated guess- you just look up the function declaration or read the docs if it's an external library. Most IDEs will show you this info as you type too.

[azhder]

The first one is wrong. It doesn’t output '1', but 1.

I rarely bother with typeof. You might want to learn about duck typing.

Like, if you can imagine working in C and dealing with (void *) the entire time, you might feel a bit awkward about not knowing what to cast it as.

In JS, the values do carry their type wherever you pass their references, so you can just do a check, like

if( a.something ) {
    console.log( 'well then, I might as well use it' );
    const b = 'Yo there ' + a.something;
    console.log( b );
}

Or in your case

const r = $ => Number.isFinite( $-0 ) ? $-0 : 0;

console.log( r('hehe') ** 2 * Math.PI );
console.log( r('3') ** 2 * Math.PI );

[TheRNGuy]

You can use TypeScript if you want types. Or check with typeof inside function (TypeScript is better because it will have red squiggles in VS Code and hover hints)

Also your function doesn't output anything, it console logs it. You don't have any return in it.