SummerAcademy on Debugging — 2.1.3 IDEs

Original Story on our blog https://www.deepcode.ai/blog/summeracademy-on-debugging-2.1.3-ides

See the companion video here https://youtu.be/mPR6tNfX1Tk

There are several developer tribes out there: The tribe of Visual Studio Code or WebStorm or Sublime or Atom or VIM or … whatever. Every tribe has good arguments and sometimes developers change the tribes. We will not tell you which tribe to join here but whatever IDE or editor you use, make sure to get the most out of it. The IDE or editor your most important tool. Make it count.

“Fat” IDEs vs “Slick” Editors

There is a spectrum between “slick” editors on the one side and full-blown “fat” Integrated Development Environment (IDE) on the other. Editors such as edlin (yes, still alive and kicking on Windows 10), vi, emacs, and many, many more, provide from simple editing to text processing via scripting to plug-ins providing rich feedback and editorial help. The shift from editor to IDEs is a bit blurry as a fully equipped editor comes close to an IDE. An IDE is a collection of tools built around the developer workflow (see IntelliJ and the list of tools it includes and be impressed).

Whether you are using an editor or an IDE and which of those depend on the environment you have (the more exotic, the more you are on yourself) and the time you can invest. From a debugging perspective, the IDE’s task is first information retrieval (navigating the source code, the configuration, log output, debugger, profiler…) and secondly, the agent to apply and test changes. This is a lot.

Some things, we really like on IDEs:

• Editor handling character encoding and able to manage HUGE files, basic stuff like search-replace with regex
• Grammar/Syntax plugins for filetypes/languages you use, syntax highlighting, typo feedback
• Interface Debugger and Performance Profiler
• Integration of Version Management System
• Display error and messages of CI pipeline
• Display error and messages of CD pipeline
• Including messages of Linters and Static Code Analysis
• Access to documentation

If your environment does not all of the above, think about how to expand. For VSC, Microsoft provides “recipes” for different environments (see resources below) also for NodeJS.

Today and in JavaScript, Visual Studio Code (VSC) seems to be a defacto standard. There some interesting observations we want to share:

• IDEs no longer need to run locally. There is a containerized VSC-like IDE calledGitPodthat provides a lot of the goodness while having zero local footprint. You can use the DeepCode plugin for VSC right in it.
• Below we have a link to some VSC tips and tricks and some cheatsheets with keyboard shortcuts. Especially when new to an environment, having the cheat sheets helps to learn the nifty shortcuts.
• Do some plugin shopping by browsing the VSC marketplace. Check out the DeepCode extension :-) Also, share what you find with your colleagues (first with the architects if you happen to have) and review to the toolbox. Maybe you want to have a company default configuration that you can expand individually as needed.

Setting up VSC to debug Node

Debugging in VSC comes in two flavors: Build in such as NodeJS and using extensions such as Python, C/C++, C#, and others. Make sure to have a look at the marketplace for your environment.

Debugging itself is actually pretty straight forward. Pressing F5, or using the Run Command (Ctrl+Alt+D), we will be offered to Run and Debug and asked which environment you prefer. Select Node.js and off you go. VSC provides breakpoints, variable watch, and Call Stack plus a debug console.

(1) The console can do more for you than simple console.log(). Try console.table() and console.dir() to format the output, or console.group() and console.groupEnd(). All in all, the console is a quite powerful tool. (2) In the command palette (Shift+Ctrl+p or Shift+Cmd+p), you can find Debug Attach to Node Process. With this, you can attach to already running NodeJS processes. (3) Best way to configure your debugging in VSC is to use a launch.json file that records all the configuration for you. The easiest way to get a boilerplate is to start debugging and watch out for the orange dot on the wheel. Press on it and select your environment. In the case of NodeJS, VSC generates a launch.json for you that looks like this. More Attributes here :

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "program": "${workspaceFolder}\\app.js"
        }
    ]
}

(4) Using docker containers as an environment to run your debugging in, makes a lot of sense. There are several ways in doing it, let us mention one. You attach to the remote container running your NodeJS app. An example launch.json looks like this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "attach",
            "name": "Docker: Attach to Node",
            "remoteRoot": "${workspaceFolder}",
            "localRoot": "${workspaceFolder}"
        }
    ]
}

By the way, DeepCode provides plugins for VSC, Sublime, IntelliJ, and Atom. And the VSC Extension can be used inside of GitPod.

Key Take-Aways

Your IDE needs to feel home. Make it so by having a default environment and then make it fit your needs.

Resources

VSC Tips&Tricks

VSC Debugging Recipes Using VSC to Debug NodeJS Apps

IntelliJ IDEA Pro Tips

Cheatsheets with VSC Keyboard Shortcuts (macOS, Windows, Linux)