Exploring JavaScript development tools (1)

1. Introduction 

Java, C #, and other advanced statement development tools are dazzling. However, the JavaScript language, as the main character of AJAX, maintains an uncommensurate silence in supporting development and issuance. Lack of support for good development tools, writing JavaScript programs, especially JavaScript programs with more than 500 lines, has become a deep challenge-no code induction function, no real-time error check, no breakpoint tracking debugging ..., Developing JavaScript code is sometimes like working in a dark tunnel with a touch. The Code accidentally adds a redundant "(" or "{". The entire code may immediately look like a collapsed wall. The errors reported in IE often seem to be false, it is often 108,000 different from the actual cause, making people look like they are in the fog. Some may cite Liu Chuanzhi's sentence to summarize the feeling of writing JavaScript programs: the treasure of war is like a thin ice.

I have used low-level text editing tools to develop JavaScript programs, which has been deeply bitter and difficult to debug for countless times. Fortunately, many good development tools have finally been found, and the darkness has ushered in the bright future.

2. Knife farming

Some time ago, I used Notepad to develop JavaScript programs: writing a program requires switching back and forth between the JavaScript development manual and the coding window constantly; writing and debugging requires synchronization at all times: after writing a few lines of code, I started the test and used alert () to output the result. I can continue writing a few lines until the current result is correct, then we re-use alert () to check the situation, and then repeat the week.

Writing JavaScript code in Notepad, new, if, else, and other well-known "Key Figures" are already "simple"-there is no difference with variable names, constants, and functions. Therefore, when the amount of Code expands, it will take about 200 lines.) code structure organization, context Association viewing, pre-and post-logical reading, and code refactoring become difficult, making people physically helpless.

This simple, original, farming-and-fire programming makes me sigh with the profound teachings of "the desire for good, the first benefit, at the same time, I also pay tribute to the feat of using only crude tools to create countless great miracles.

3. Scalpers

Compared with Notepad, editing tools such as Editplus, UltraEdit, and Editeur are much more comfortable. These editing tools highlight language keywords and display objects, constants, and Other semantic elements in different colors. At the same time, these tools are also aware of the program code structure, for example, when the cursor changes in a code block, the cursor is automatically indented. Figure 1 shows how EditPlus edits the JavaScript program:

Figure 1: EditPlus edit JavaScript Program

In addition, these tools generally have powerful search, replacement, block operations, and other editing functions. Non-Notepad can speak the same day. So the imperfect scalpers such as EditPlus have helped us out of the nightmare of full human labor. Until now, most developers should still use such editing tools, and most of the JavaScript programs completed by the author are also completed in Editplus.

Although the EditPlus editing tool makes code structure arrangement and context search much easier, it still does not have code-induced functions, let alone program breakpoint tracking and debugging. Here, the alert () function still plays a role in debugging. Of course, you can add the alert () statement where you need to pay attention to it to view the runtime information. This kind of work like mine tracking is not hard, however, disassembly and adjustment work is complicated and laborious. Besides, alert information such as rain is enough to drive a normal person crazy.

Alert can only view the running status of a single point of operation and cannot record the process information of the program running. Therefore, when the program exceeds 400,500 lines, the debugging process will become step-by-step. In view of this, I have developed a debugger embedded in the program following the idea of Log4J in Java. The idea is probably like this:

1) embed JavaScript into the html page, and provide one in the page. Use this div to display information about the program running.

2) provide a method for outputting procedural debugging information:

1. function appendDebug(info,color) 2. ...{ 3. /**//*if(appendDebug.arguments.length < 2) 4. { 5. color = "black"; 6. } 7. document.all("debugInfo").innerHTML += " "+info+""; 8. */9. }

Open the code annotation code in the method when debugging is required.

3) at the debugging point of the program, call appendDebug (info) to output the debugging process information, as shown in the following sample code:

Function fun1 (param1, param2) ...{ ... AppendDebug ("the input parameter param1 value of fun1 is" + param1, "blue "); ... AppendDebug ("the input parameter param2 value of fun1 is" + param2, "yellow "); ... }

In this way, the procedural information during the running of the program can be recorded in different colors for debugging purposes.

In the absence of a debugger, this local stove really helped me a lot, this method is used to debug the JavaScript programs of "intelligent Induction Control in the drop-down box" and "multi-function calendar control" with nearly 2000 lines of code. This method is still instructive because the existing JavaScript debugging tools are not powerful enough.