Encountering the cascading expression trap in JavaScript_javascript tips

I still vaguely remember that when learning library functions in C language, many functions related to string operations will return pointers related to the results. In fact, this return value is not very necessary in many cases, because most of the parameters we pass in already contain this pointer. The biggest advantage of adding this return value is that it allows us to easily write cascade expressions. But in these years of actual work, I feel more and more that cascade expressions are a devil's pie.

For example, in C language, we are familiar with the string operation functions strcpy, strcat, etc. Their prototypes are generally: extern char *strxxx(char *dest, char *src);
Return value char *In fact, it is to call *dest in the parameter, so that you can easily write cascade expressions, as follows:
char *title = "Mr. ";
char *name = "birdshome";
int len ​​= strlen(strcat(title, name));
In object-oriented programming, we can write chain expressions by returning objects through methods. Although whether it is a cascade expression or a chain expression, it can make us more convenient when writing code, but if used improperly, it can also be very frustrating. Especially for cascading expressions, if there are too many nested functions, it will be difficult to understand and debug will be very frustrating.

The following JavaScript cascade statement made me depressed 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 the penultimate bracket ")". Originally this bracket should be after the parameter levelTypes, but I didn't pay attention and got it in front of levelTypes. This is a writing error. , it is very difficult to see it at a glance. What's even more depressing is that JavaScript is not interested in the number of parameters of the function or whether there are parameters at all, so this wrong statement can run "normally", but after the data is transferred to the background, the required value cannot be obtained. Always undefined.

In addition, there are composite parameter calling statements, which if properly expanded will bring us a lot of benefits, such as code:
var rect = dashboard.getBoundingClientRect();
this. InsertNewRoom(dashboard, event.clientX-rect.left-1, event.clientY-rect.top, event);
The code after expanding the composite parameters is: var rect = dashboard.getBoundingClientRect();
var innerX = event.clientX-rect.left-1;
var innerY = event.clientY-rect.top;
this.InsertNewRoom(dashboard, innerX, innerY, event);
Although this expanded code No additional logic is added, but the statement that adds temporary variables innerX and innerY is obviously much easier to understand than the statement with composite parameters. Although there is more code in this way, it makes the code self-documented without changing the logic and efficiency of the code. I believe that when debugging or modifying other people's code, you want to see the latter way of writing.