I believe that many people will go to Github to see some excellent open source projects in their spare time and improve themselves by learning the source code of these projects. However, most of the excellent open source projects are characterized by complex process and large amount of code. Without certain skills, I believe that many developers will be just like the author in the early days. Lose yourself in a sea of code
Conclusion: The most efficient way to look at code is to look at it while debugging and recording.
Since different people have different recording habits, this article will not discuss this topic.
Debugging is the silver bullet of the source code
When we look at the source code, we usually encounter the following problems:
- There are too many files, and looking back and forth between files causes confusion
- There are so many branches of code that without data it is difficult to determine the current branch of code execution just by memory and imagination
- You can’t tell what a method returns, and you have to look at the method source code to make a basic judgment, resulting in a lot of code to digest to understand the process
- .
Debugging allows us to understand the overall process faster
Given input to debug, we can easily know the result of each step of execution without having to worry about the internal implementation of the method, which allows us to understand the overall execution flow of the code with only a few files to focus on.
Debugging allows us to focus only on local implementations
If we want to understand the internal implementation of a method, we can debug the breakpoint directly inside the method: by entering the given data and starting the debugging, the editor will automatically locate the breakpoint, and then step through every line of the method body, knowing the result of each step of the code execution.
How to debug
As I usually develop the editor is VS Code, so the following will mainly describe some debugging operations in VS Code.
VS Code has integrated browser, node. js, and TypeScript debugging capabilities. For details, see the official documentation links: browser-debugging, nodejs-debugging, and typescript-debugging.
The following will be some specific examples to take you to appreciate the charm of debugging.
Preview of vscode debugging
Front-end debugging of VS Code is very simple and requires the following four steps:
- Select Debug in the editor (as shown in Step 1 above)
- create
launch.json
The file (as shown in Step 2 above) will be created in the source root directory after this step.vscode/launch.json
- configuration
launch.json
- Start debugging
launch.json
Configuration is introduced
The launch.json created by the above operation looks like this:
{
// Use IntelliSense to learn the properties.
// Hover to see the description of the existing property.
/ / for more information, please visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0"."configurations": [{"type": "node"."request": "launch"."name": "Start procedure"."skipFiles": [
"<node_internals>/**"]."program": "${file}"}}]Copy the code
We only need to focus on each configuration in our Configurations:
type
: debugger type, where usenode
To execute the programrequest
: represents how to start the debugger, yesattach
和launch
Two valuesattach
: If the Node program is already started, append debugging to the already started programlaunch
: Starts the program directly with the debugger and starts debugging
name
: Indicates the name of the configurationskipFiles
: Debug ignored files. After the configuration, the matched files will not be entered in the single-step debuggingprogram
: Program start entry
In addition to the above configuration items, the author believes that there are several configuration items that are worth your attention:
runtimeExecutable
: What command is used to start debugging, e.g. the above configuration is used by defaultnode
To perform theprogram
The fileargs
: specifies the startup parameterconsole
: You are advised to set this parameter tointegratedTerminal
, so that debugging information is displayed on VS Code’s built-in terminalrestart
: set totrue
, the system automatically restarts after modifying the code and saving itstopOnEntry
After debugger starts, whether to pause at the first line of code, a very convenient configurationport
: Indicates the port used for debuggingcwd
: The root directory where the debugger works- .
For more parameters, please refer to the official document:
- nodejs-debugging#_launch-configuration-attributes
- debugging#_launchjson-attributes
Json also contains some specific template variables, such as the program attribute value ${file} above. Here’s what each template variable means:
${workspaceFolder}
: The directory where the folder is open in VS Code (usually the location of the project)${workspaceFolderBasename}
: Directory of folders opened in VS Code without any slash (/)${file}
: The absolute location where the file is currently open${relativeFile}
: The current location of the open file relative to the workspaceFolder${fileBasename}
: The name of the current open file (with an extension, such astest.js
)${fileBasenameNoExtension}
: The name of the extension name of the current open file (no extension name, such astest
)${cwd}
: Indicates the current execution directory${fileDirname}
: The directory where the file is currently opened${fileExtname}
: The extension of the current open file${lineNumber}
: The number of lines currently selected in the file${selectedText}
: Indicates the current selected content in the file
In summary, the configuration of the above launch.json is to debug the currently open file using node, assuming that a.js is currently open and a breakpoint has been set, as shown in the following figure:
Debug Vue3 source code
Let’s use the Vue3 code as an example for a debugging demonstration.
First copy the Vue3 code and enter it into the project directory:
git clone https://github.com/vuejs/vue-next.git
cd vue-next
Copy the code
You can see that the Vue3 project has a debug configuration:
{
"version": "0.2.0"."configurations": [{"name": "Jest"."type": "node"."request": "launch"."program": "${workspaceFolder}/node_modules/.bin/jest"."stopOnEntry": false."args": ["${fileBasename}"."--runInBand"."--detectOpenHandles"]."cwd": "${workspaceFolder}"."preLaunchTask": null."runtimeExecutable": null."runtimeArgs": ["--nolazy"]."env": {
"NODE_ENV": "development"
},
"console": "integratedTerminal"."sourceMaps": true."windows": {
"program": "${workspaceFolder}/node_modules/jest/bin/jest"}}]}Copy the code
This configuration is of type Node, but runtimeExecutable is null, so instead of using the default Node to execute the file, the program executable jest is used to execute the file.
So what is the execution file? The answer is ${fileBasename} in args, which is the currently open file. Therefore, when we open a *.spec.ts file, we can perform debugging in this file.
Vue3 Main process debugging
The built-in JEST debugging can only debug local methods, so what if we needed to understand the main flow of Vue3 execution?
Open the Packages directory and you will see the vue directory. The directory structure looks like this:
├ ─ ─ __tests__ │ ├ ─ ─ the Transition. The spec. The ts │ ├ ─ ─ TransitionGroup. Spec. Ts │ ├ ─ ─ e2eUtils. Ts │ ├ ─ ─ but the spec. The ts │ ├ ─ ─ RuntimeCompilerOptions. Spec. Ts │ ├ ─ ─ svgNamespace. Spec. Ts │ └ ─ ─ the transition. The HTML ├ ─ ─ API - extractor. Json ├ ─ ─ examples │ ├ ─ ─ __tests__ │ │ ├ ─ ─ commits. The mock. Ts │ │ ├ ─ ─ commits. The spec. The ts │ │ ├ ─ ─ the grid. The spec. The ts │ │ ├ ─ ─ markdown. Spec. Ts │ │ ├ ─ ─ SVG. Spec. Ts │ │ ├ ─ ─ todomvc. Spec. Ts │ │ └ ─ ─ tree. The spec. The ts │ ├ ─ ─ classic │ │ ├ ─ ─ commits. The HTML │ │ ├ ─ ─ the grid. The HTML │ │ ├ ─ ─ │ ├── html.htm │ ├── html.htm │ ├── html.htm │ ├── Html.htm │ ├─ html.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm │ ├─ HTML.htm Grid. HTML │ │ ├ ─ ─ markdown. HTML │ │ ├ ─ ─ SVG. The HTML │ │ ├ ─ ─ todomvc. HTML │ │ └ ─ ─ tree. The HTML │ └ ─ ─ the transition │ ├ ─ ─ the list. The HTML │ └ ─ ─ modal. HTML ├ ─ ─ index. The js ├ ─ ─ node_modules ├ ─ ─ package. The json └ ─ ─ the SRC ├ ─ ─ dev. Ts ├ ─ ─ but ts └ ─ ─ the runtime, tsCopy the code
The *.html in examples is sample code for various Vue3 features. By debugging these files, we can see the overall execution flow of Vue3.
Each of these HTML files introduces a.. /.. /dist/vue.global.js file, we first build by command, go back to the project root directory and execute:
yarn dev --sourcemap
Copy the code
Then, install the Debugger from Chrome extension in VS Code:
Add the launch.json configuration:
{
"type": "chrome"."request": "launch"."name": "Launch Chrome"."url": "http://localhost:8080"."webRoot": "${workspaceFolder}"."file": "${workspaceFolder}/packages/vue/examples/composition/${fileBasename}"
}
Copy the code
This configuration allows us to debug packages/vue/examples/composition/under all *. The HTML file, debugging other directories of files can be achieved by modifying the file path.
Next, we tested whether debug configuration to take effect, in the packages/vue/examples/composition/commit. HTML hit a breakpoint, Basecomcompile in packages/compiler-core/ SRC /compile.ts
As you can see, the program in the debugger code suspended, through single step over into createApp (located in the packages/runtime – dom/SRC/index. The ts), through to the next breakpoint F5 again, Packages /compiler-core/ SRC/compiler.ts
There you go. Have fun reading the source code for Vue3
ts-node
Debug the TypeScript
Without going into the popularity of TypeScript, here’s a quick tip for debugging TypeScript directly in *. Ts files: Using a TS-Node execution program, configure it as follows:
{
"version": "0.2.0"."configurations": [{"type": "node"."request": "launch"."name": "Launch TS"."runtimeArgs": ["-r"."ts-node/register"]."args": ["${workspaceFolder}/test.ts"]},]}Copy the code
conclusion
Debugging is not only an important way for us to troubleshoot problems, but also an efficient way for us to view the project’s source code.
This article introduces the advantages of debugging in looking at the source Code and the knowledge of debugging in VS Code. Due to the limited space and the scope of my knowledge, there are a lot of knowledge points for readers to explore. I hope you can point out any errors in the comments section. It is not easy to be original. I hope you can give more praises ~ ~ ~