Suppose you want to ‘sum’ a text string and a number. That is not a problem for JS. An implicit type conversion will mutely translate something like "abc" + 12 into "abc" + "12" (resulting in the string "abc12"). In the geek dialect, this mechanism is referred to as duck typing.

But the assets of weak/duck typing have a counterpart: types are not visible in the code.

function enigma(obj, val)
{
for ( var p in obj )
  if ( obj[p] == val ) return(p);
return('');
}
 
alert(enigma(SpecialCharacters,0x53456D53));
 

Within the script above, the enigma function will return the friendly name of an Enumeration id, but it is pretty hard to predict, isn't it?

As everybody knows, properly commenting the code is a key practice at any level of programming. If your intention is to re-read and improve your scripts, use unambiguous names for functions/variables and write as many comments as you need to stay in the lane.

To keep some type-visibility in declaring a function, a good approach is to imitate the C syntax — <return-type> functionName(<data-type><arg>...) — by commenting the code this way:

/*str*/ function typedEnigma(/*class*/ obj, /*int*/ val)
// ----------------------------------------
// Returns the friendly name of the id <val>
// from the Enumeration class <obj>
// If <val> is not a valid enum value, returns ''
{
for ( var p in obj )
  if ( obj[p] == val ) return(p);
return('');
}
 

It may not be a perfectly commented code, but at least it displays the kind of arguments expected by the function, and the kind of result supposed to be returned.

Here are the main keywords I use for commented types:

KEYWORD TYPE
/*str*/ STRING
/*int*/ NUMBER (integer)
/*bool*/ BOOLEAN
/*arr*/ ARRAY
/*flo*/ NUMBER (float)
/*var*/ VARIANT
/*obj*/ OBJECT
/*reg*/ REGEXP
/*fct*/ FUNCTION