Cascading expression traps in JavaScript

Vaguely remember, when learning C language library functions, many string operation-related functions will return results-related pointers. In fact, this return value is not very necessary in many cases, because the pointer is included in all input parameters. The biggest benefit of adding this return value is that it allows us to easily write cascade expressions in books. However, in actual work over the years, cascade expressions have become a devil pie.

For example, in C language, we are familiar with the string operation functions strcpy and strcat. Their prototype is generally: extern char * strxxx (char * dest, char * src );
The returned char * is actually the * dest in the call parameter. This allows you to easily write cascade expressions, as shown below:
Char * title = "Mr .";
Char * name = "birdshome ";
Int len = strlen (strcat (title, name ));
In object-oriented programming, we can write chained expressions by returning objects through methods. Although neither cascade expressions nor chained expressions can make it easier for us to write code, improper use of them will also be quite depressing. Especially for Cascade expressions, if the function is nested too much, it is hard to understand it, and debug will also be very depressing.

The following JavaScript cascade statement has depressed me for a long time... DimInfo. push (StringHelper. ArrayToString (item. m_DimensionName,
Item. m_DimensionUniqueName, item. m_AnalysisStatus,
(Item. m_IsParameterized? 'Checked': ''), item. m_DimensionType), levelTypes );
The correct statement should be the following: dimInfo. push (StringHelper. ArrayToString (item. m_DimensionName,
Item. m_DimensionUniqueName, item. m_AnalysisStatus,
(Item. m_IsParameterized? 'Checked': ''), item. m_DimensionType, levelTypes ));
The problem lies in ")" on the last and second parentheses. Originally, this bracket should be placed after the levelTypes parameter, and the levelTypes is not mentioned in the result, it is very difficult to see at a glance. Even more depressing, JavaScript is not interested in the number of function parameters and whether there are any parameters. Therefore, this incorrect statement can run "normal", but after the data is uploaded to the background, the value is always undefined.

In addition, there are composite parameter calling statements. If we can expand it appropriately, it will bring us many benefits, such as the Code:
Var rect = dashboard. getBoundingClientRect ();
This. InsertNewRoom (dashboard, event. clientX-rect.left-1, event. clientY-rect.top, event );
Code for expanding the composite parameter: var rect = dashboard. getBoundingClientRect ();
Var innerX = event. clientX-rect.left-1;
Var innerY = event. clientY-rect.top;
This. InsertNewRoom (dashboard, innerX, innerY, event );
Although the expanded Code does not add any additional logic, the statements with the temporary variables innerX and innerY are much easier to understand than the statements with compound parameters. In this way, although the Code is too much, the Code has the self-defined ented feature and does not change the logic and efficiency of the Code. I believe that when debugging or modifying others' code, you want to see the latter method.