Visual Studio Code offers an incredible depth of customization, but not every setting has a dedicated "toggle" command. Some features are essential in one moment but become distracting clutter the next. My journey with this started when I wanted to use relative line numbers. I quickly realized there wasn't a native way to dynamically switch between relative and absolute numbers, or hide them on a whim.

Fortunately, there is a solution. The Settings Cycler extension allows you to define a list of values for any setting and "cycle" through them using a custom keybinding:

How it works:

1. Install the extension.

2. Define your “cycling” options in your settings.json file under “settings.cycle".

3. Open Keyboard Shortcuts and assign a key combo to your new command (e.g., settings.cycle.lineNumbers to a Caps Lock + L).

May the Force be with you.

—Petr

Most people are, euphemistically speaking, economical with software requirements.

Clients, users, product owners, team leaders, and other ticket-writers typically don’t obsess about details. While laziness and knowledge gaps play their role, it also happens due to implicit expectations.

Implicit requirements are unstated, but expected, features or characteristics, that are so fundamental they are not written down or discussed. For instance, a client asking for a mobile app most likely expects to find it in the app store, a ticket for dark theme support might imply automatic switching based on system preferences, or a request for multi-factor authentication might imply an admin area to restore access for users who lost their phone.

The trouble is, of course, that people don’t share a common mind. And while idea-makers can live in a fuzzy world, developers don’t have that luxury. Regardless of seniority, developers require clearer specifications on of what needs to be done.

Every time you accept a feature request or a ticket, either for yourself or for your team, it makes sense to stop and identify implicit requirements. Similarly, it is important to do the same when creating work for others.

Assumed requirements are a liability. They lead to:

• Inaccurate estimates

• Invisible scope creep

• "guess-driven development"

• Testing gaps

Ultimately, implicit requirements result in costly rework that leaves everyone unhappy.

So be cautious, ask more questions, and develop that product and industry intuition over time. It also works better with more people, so include others. If you are doing something like refinement sessions, invite testers and support folks too. The result will be the best, as nobody will have to guess anymore.

When you eliminate the guesswork, you eliminate the risk.

PF 2026

—Petr

“Surround with snippet” are a special type of code snippet that operate on selections. You can use them for many language constructs that typically have some code “inside” them, e.g., if statements, try/catch blocks, and so on. Many of these things are also available as “normal” code snippets, but using Surround with snippets makes it easier to turn already existing code into something else.

Visual Studio Code has them built in, although they don’t have a keybinding by default. You can access them under the Snippets: Surround with Snippet command in the command palette (F1) whenever some code is selected (multiple selections are supported too). Once run, you can then select which snippet you want to use:

Alternatively, set Editor > Snippets > Code Actions: Enabled to true. VS Code will then offer these snippets as code actions (CTRL + . whenever some code is selected).

Surround with snippets are like other snippets in Visual Studio Code: some come built-in, some through extensions, and you can create your own. The concept itself is general—you can find “surround with” snippets in other editors or other extensions under different names.

My favorite variation is actually built into VS Code already: Emmet: Wrap Abbreviation command makes it convenient to restructure HTML code:

And that’s it. Happy weekend coding.

—Petr

Applications and entire software systems don’t run in a vacuum; they run in environments consisting of compatible hardware and software. Such environments can encompass a wide range of elements, from infrastructure like databases and cloud services, platform requirements (e.g., browser versions and operating systems), hardware requirements (e.g., memory and CPU requirements), and even network components.

Being clear on what the compatible environments look like can help software teams, customers, and users throughout the development lifecycle (planning, development, testing, and production use) to:

• understand the project’s scope

• estimate the effort required for development and testing (as more compatible environments directly increase the effort)

• set up development, staging, and production environments

• estimate costs to develop and run the software

• make a test plan

• triage bugs

• (customers) make purchasing decisions or formulate requirements

• (users) run applications correctly

• …and probably many other things.

For practical documentation, I recommend separating compatible environments into three main groups:

• Tested: environments that are or will be directly used for testing, or which developers use during development. (Almost) guaranteed to work properly.

• Supported: environments that you want to support but don’t have the resources to test as part of the development lifecycle. If an application doesn’t run correctly in a supported environment, it is a bug.

• Recommended: the optimal configuration of hardware and software for achieving peak performance, security, and stability.

The most important category is supported environments, because it ultimately determines what is a bug. This helps users to know whether to file a bug report or software teams with development planning and bug triage. A whole lot of bug reports can often be completely dismissed by just examining the user’s environment.

Sometimes it is beneficial to warn or restrict users when the environment is incompatible. For example, streaming services will restrict users, refusing to play content in unsupported browsers. Conversely, server-side software may simply log a warning upon detecting a minor environmental incompatibility.

Documenting supported environments is practically a must-have for any serious software that ends up in the hands of customers and users, including client applications that require browser and operating system compatibility and self-hosted server software.

Tested environments help with forming a test plan. Specifically, they drive the strategy for test automation and regression testing, clarifying which software and hardware combinations must be covered before a release or deployment. Tested environments also provide guarantees to users and customers in the “If you want the software to work, use this” style. Many software libraries are tested against a matrix of various dependencies, for example.

The scope and format of the documentation are going to be dependent on your context. You might prefer text and warnings for customers, for instance, while tested environments might be simply captured by your CI pipelines and automated development environments. Regardless of the format, being clear ensures that the development team, customers, and users are always on the same page.

—Petr

Terminal emulators with tab support (opening multiple shell sessions at once) can often be controlled programmatically. Terminals that don’t might still offer split-screen or the ability to start a completely new terminal window.

The usefulness of this feature lies in the ability to accept a command that will be started in the new shell session. This is similar to using shell-based terminal multiplexers like tmux. In both cases the idea is to conveniently start multiple or separate things that can be controlled independently.

As an example, think about enhancing a project entry point that uses Docker Compose. By default, Docker Compose starts all containers, and the output from all services is displayed together in the same terminal window. However, with programmatic tabs, you could also create independent terminal tabs that attach to each container.

With tabs attached to the running processes, you can kill and restart things in the containers just by navigating to their tab and ending a process using classic CTRL+C or starting it again with shell command history—without the need to deal with the containers externally. In fact, this is how the default development entry point script works in Baserow:

Because the tab control differs across terminals, I recommend using a program like ttab that can handle a variety of terminals, although for personal use cases it might be enough to write terminal-specific commands. ttab also supports opening things in new terminal windows and split-screen setups for compatible terminals.

I believe that programmatic terminal multiplexing is great for improving local development experiences. What about you?

Have a nice weekend,

—Petr

(And check out my Command Line Handbook for more command-line stuff if you haven’t yet.)

Whenever a cursor is placed at a recognized symbol, VS Code will highlight all the symbol occurrences in the opened file. That’s great for visually identifying all the places the symbol is used, but also for selection and navigation.

Visual Studio Code allows you to navigate between these highlights using the Go to Next Symbol Highlight (default F7) and Go to Previous Symbol Highlight (default Shift + F7) commands.

This feature is ideal for quick, focused navigation within a single file, without the need to use search or a more complex approach. You can use it for a lot of things:

• Going from where a symbol is defined or imported to where it is used

• Jumping between the children of a parent class (as you will typically have the same symbol defining the inheritance)

• Tracking and tracing the usage of a variable in a class, method, or function

• Going between opening and closing tags in HTML or XML

• Cycling through the locations of the same word in a text or Markdown document

Let’s see it in action:

Note that when you place your cursor on a variable name (or another language construct), it will highlight all its occurrences within the same scope. On the other hand, placing the cursor in a string, comment, or text document will highlight all the word occurrences in the file, as there isn’t any scope to restrict it.

For example, if a function's documentation mentions the function's name, you can jump from that documentation to the function's definition. However, the reverse is not possible; you cannot jump from the function's definition back to the documentation, unless the text occurrence was highlighted first.

—Petr

Today, I want to discuss a big benefit of writing documentation that is often ignored: driving improvements to confusing and convoluted solutions.

And by documentation, I really mean all kinds of documentation you can find in software development:

• Source code documentation

• API documentation

• Design and architecture documentation

• Process documentation

• User-facing documentation

• …

When you try explaining something to someone else, the flaws and gaps become obvious:

• If you dislike explaining how the combination of five parameters works together in a function signature documentation, perhaps you are missing a better abstraction in the code to express the complexity.

• When writing a tutorial on how to use your external API to achieve a common use case takes several API calls, maybe the right solution is to add a use-case-specific endpoint.

• If the documentation for handling tickets is 10 pages long, perhaps the process should be simplified.

• Describing how to run a development environment using three commands is not fun. Just make a better entry point to the project.

All these examples show that it doesn’t matter what the documentation is for. The process of writing documentation can trigger a re-evaluation of the solution itself, creating a continuous feedback loop: Document → Identify problems → Improve.

The ultimate goal is a solution so well-designed that its documentation becomes minimal and more self-explanatory, but to achieve this, it's often necessary to document the initial, more complex version first.

—Petr

A subset of the smart actions are integrated into the Visual Studio Code Quick Fix menu, which has been Visual Studio Code’s solution to invoke various refactoring tasks (like Extract method, Move symbol, …) based on the cursor position in the code. The best way to invoke it is with a keyboard shortcut (by default Ctrl + .) or by clicking on the lightbulb icon 💡.

Smart actions are helpful whenever we aim for AI-assisted development where writing code manually blends with targeted use of AI tools.

Depending on the context, the Quick Fix menu will typically offer some combination of the following smart actions: Generate, Modify, Review, Generate documentation, Generate tests, Explain, and Fix.

Some actions show a prompt dialog first to provide instructions (Generate…), and some show the same prompt dialog after the action is done (further prompting after action was taken). In both cases you can choose the model to use, use voice commands, or invoke slash commands when it makes sense:

Generate

Generate smart action is available on blank lines for generating new code. This action is the same as any other “generate code” approach, but with the advantage of placing the new code exactly when you want it. Things like writing a new method for a class, adding some logic to an existing function, and so on. Writing new code using the Generate action is faster than using agents for smaller blocks of code.

Modify

Modify smart action is displayed whenever code is selected, perfect for in-place modification and code rewrites. It is like “AI refactoring,” where you can ask for renames (e.g., converting between camelCase and snake_case), rewriting classes to functions and back, converting divs into semantic HTML structure, and so on.

Review

Review smart action instructs the GitHub Copilot to provide a code review when some code has been selected. However, the result is not just textual feedback, but rather a series of proposed enhancements that you can go through. You can accept or reject each of them separately.

One interesting use case for Review smart action is to run it on previously generated code to see if the AI code itself can be improved.

Generate documentation

Generate documentation action appears when the cursor is placed at a symbol that is typically documented (think class and function names). You can easily add language-specific descriptions in the form of, e.g., JSDoc for JavaScript or Python’s docstrings. It is handy when you don’t remember all the syntax for documenting function parameters and other specifics.

Generate tests

Generate tests is displayed when the cursor is placed at symbols that are typically unit tested, like method and function names. It will create one or more tests without providing any description first. After the test code is generated, you will get the ability to further prompt the model for modifications.

Explain

With the Explain action, you can directly get a short summary of what certain code does or explore problems highlighted in the editor. I find it strange that the Explain action is not offered when any code is selected, as it only appears when selected code has a problem identified within or when the cursor is placed directly at some problematic code.

Anyways, you can invoke the Explain action with a small detour even if it is not offered in the Quick Fix menu. Use the slash command /explain in the Modify smart action text area instead:

Fix

Fix action is similar to the Explain action as they are both available for code with already identified problems. So to invoke it, you will need the editor to be aware of the problem first.

There is also the Fix test failure action that can be invoked from within test code that failed. Again, the editor needs to be aware of the problem, so such action will be available only when using the integrated test runner.

I am quite happy with Quick Fix smart actions, as it provides “AI assistance” when writing code manually without the need to resort to more complicated AI tools.

What is your experience?

—Petr

When executing long-running commands in the terminal, it is useful to get notified when they are done, instead of checking the terminal manually.

Personally, I am using the Linux notify-send utility program to produce toast-style system notifications. In my desktop environment, notify-send produces notifications at the right level of intrusiveness, and the notification stays in the notification center in case I want to get away from the computer entirely. But nothing stops you from being creative here; macOS users can leverage the native say command to get an audio notification, for instance.

The basic pattern involves putting the notify command of your choice after your long-running task (notice the semicolon):

> ./takes-long.sh ; notify-send "Task finished"

If you want, you can get notified only on success, on error, or have a different message for success and error:

> ./takes-long.sh && notify-send "ended with success"

> ./takes-long.sh || notify-send "ended with error"

> ./takes-long.sh && notify-send "ended with success" || notify-send "ended in error"

> if ./takes-long.sh; then notify-send "ended with success"; else notify-send "ended in error"; fi

While not bulletproof, combining short-circuiting operators && and || together will work as expected as long as the notify-send command works properly. This style is less verbose than the proper if-else structure shown in the last example.

I also like to alias notify-send to just notify. You might want to do something similar. You can find more about aliases and short-circuiting operators in my Command Line Handbook.

—Petr

The tech industry is obsessed with “best practices.” People are constantly on the hunt for the latest and greatest processes, tools, and technologies. And yet, despite all the preaching and debate (…and thousands of influencer videos), you will hardly find anything “the best.”

The problem is not just that “the best” is a moving target in the fast-paced technology world, but that it's always a context-specific decision.

What is best for a solo developer, agency, startup, or an established enterprise will be very different. The ideal technology for game development won't translate to better web development, and a developer who needs specific editor integrations won't benefit from using Vim if their plugin is only for VS Code.

The obsession with “best practices” prevents people from developing decisions for themselves. Because if something is the best, why would anyone do or use anything else?

Still, people seek guidance. There are too many decisions to make in any software development endeavor. Nobody should completely ignore the lessons of people that came before. But what we need is guidance that assists in decision-making, rather than replacing it entirely.

This is where the concept of a "sensible default" comes in. A sensible default is a flexible starting point—a well-reasoned choice that we can use if we don’t have a better idea yet.

I heard the term recently on the Thoughtworks’ podcast. I really like it. And I think that every person, team, and company can develop their own “sensible defaults” that streamlines decision-making.

Ultimately, I’d like to see more of this in the industry. Let’s bring more nuance to our decisions, mention the context behind our choices, and acknowledge our blind spots. That, in my opinion, would be for the best.

—Petr

Git excludes file, often referred to as “global .gitignore,” is a file that defines global ignore rules for tracking files across all local Git repositories.

We can use it to add some extra files in the tracked folders to enhance our local experience without affecting other users:

• Custom entry points

  • Using different tools to run things. For example, using just files instead of the default project’s task runner.

  • Configuring additional tasks for local workflow.

• Custom environment

  • Adding a mise.toml file to automatically install correct runtime dependencies even if the rest of the team prefers other tools.

  • Avoiding the clutter of environment-specific files, like .DS_Store files on MacOS.

• Custom editor configuration

  • .vscode/, .idea/, and other editor-specific configs.

• Personal documentation

  • Personal README and other doc files directly where you need them.

• Custom tests and configuration

  • Working with custom and ad hoc tests by having our own test files. For example, using *.http files with REST Client extension to test API endpoints during development.

  • Using custom test configuration for a test runner.

• Temporary files and folders

  • Being able to store temporary exports for testing import/export functionality.

  • Storing uncommitted, personal test data, e.g., images, directly in the project folder.

  • Scratch files for custom scripts.

• Sensitive files

  • Keys, passwords, and so on.

While having custom files in the project folder can be awesome, it is good to mention that Git ignore rules should still be placed in the project’s .gitignore file whenever it makes sense:

• When it is expected that developers will want to adjust some behavior, provide the proper rules right away. For example, a dev.sh script with entry points can automatically source untracked pre- and post- user scripts so that the behavior can be customized.

• It is still better to make sure common OS and editor files are ignored in the project itself to prevent accidents.

• The project’s .gitignore file should always cover any project files that affect everyone, including build, dependency, and log directories, generated docs or test output, cache files, and so on.

When a project’s entry points or documentation are not sufficient, it almost always makes sense to try to improve the experience for everybody in the project first; custom files in the project folder are the last resort, in my opinion.

The rules in Git excludes file follow the same concepts and syntax as standard .gitignore files, they just act as a “parent” for all of them.

The default location of the excludes file will depend on your environment. On Linux, it will be ~/.config/git/ignore. It can also be set to a custom location:

# check if custom location of excludes file is set
git config --global core.excludesFile

# set custom excludes file location
git config --global core.excludesFile ~/.globalgitignore

If you happen to use a custom location, I recommend not naming the file .gitignore if you want to keep it under version control. In any case, it is a good idea to track the file in your dotfiles directory.

Some useful things to know:

• If you happen to work in a Git repository and you want to commit an ignored file, you can always start tracking the file by invoking git add with —force or -f flag (git add -f ignoredfile.txt). This is useful for cases where you cannot or don’t want to modify the ignore rules for some reason. The file will be tracked from that point on in the repository despite the rules.

• The use cases of the global Git excludes file can be similar to using repository-specific setting .git/info/exclude inside each Git repository. In both cases the ignore rules are personal and not shared with other users, but a big advantage of Git excludes file is the ability to be easily tracked in your own repository. .git/info/exclude could be useful for quick, ad hoc ignore rules.

And that’s it.

— Petr

This feature can be toggled when a file is open with the command GitLens: Toggle File Heatmap or by using the File Annotations menu:

When the heatmap is turned on, GitLens will add a color-coded bar with bright colors representing the newer lines of code and dim colors representing the older lines of code. The code itself is nicely dimmed according to its age as well:

As you can see, highlighting newer code makes it possible to quickly skim the file to get updated about the latest changes in general or to track down a recent bug.

The colors and the main threshold for the old and new age can be configured in the settings.

I hope you have a nice weekend and find the File Heatmap useful.

Petr

<<<<<<< HEAD
Banana
=======
Apple
>>>>>>> fruit-feature
Orange
Mango

In the situation above, we can see that the HEAD contains the line “Banana” on the first line, while the branch fruit-feature contains “Apple” instead.

We can solve the conflict manually, without using any special merge tools, by removing the markers and keeping the code we want in any text editor.

The problem with merging, though, is almost never about the mechanics of the editing but rather about figuring out what the result should look like. Should we keep the banana, apple, both, or none?

One of the best ways to help us get the context of the merge is to use three-way merge view, because it will produce a base revision (nearest common parent) along the two versions:

<<<<<<< HEAD
Banana
||||||| c0e4389
Apple
Banana
=======
Apple
>>>>>>> fruit-feature
Orange
Mango

As we can see, the original parent c0e4389 has both “Apple” and “Banana”, effectively showing that the branches were both deleting items and the conflict should be resolved by deleting both entries.

You can tell Git to use three-way merge by setting merge.conflictstyle to diff3 in the Git configuration:

# in .gitconfig
[merge]                                                                                                                                                                                                                         
    conflictstyle = diff3

Code editors can also color-code the lines when viewing conflicting files. Here is how it looks like in Visual Studio Code:

Using three-way merge view has been the single biggest improvement in my ability to resolve conflicts. If you are not using it yet, take it for a spin.

Petr

I just finished a major update to my Linux command line ebook and decided to make it available to a wider audience. So, until further notice, you can get my Command Line Handbook for any price you want.

If you didn’t know I attempted to make a modern command line introduction in PDF form or couldn’t justify paying the full price before, now is the time to get it.

I spent a lot of time making this book. It isn’t perfect, nothing is. But I sincerely believe it is useful.

Oh, and my favorite page is page 32.

Let me know what you think,

Petr

In Visual Studio Code, the Git gutter (the colorized vertical line shown next to code) is not only a visual indicator of new and changed lines but also has an integrated “peek” dialog with additional features.

In particular, the Show Next Change (default Alt + F3) and Show Previous Change (Shift + Alt + F3) are helpful when making separate changes in long code files. The dialog can be opened by clicking on the Git gutters or by using the Show Next Change keyboard shortcut.

Because the actions to move between changes have keyboard bindings, we get fast navigation between edits in the open file. Pressing Esc will hide the dialog. The video demonstrates the process:

Have a nice rest of the week,

Petr

When you end up with multiple PRs that depend on one another, you get stacked pull requests. The image below illustrates the situation:

Creating stacked PRs is simple, and one has to only go and create new branches from the correct parent, so that pr-1 would be based on main, pr-2 would be based on pr-1, and so on.

The trouble comes when branches in such a chain start to change or open pull requests from these branches get merged. When this happens, some branches will be left in a bad state, pointing to the wrong commits. Our goal is to always have the correct commits pointing to each other so that the whole chain of commits makes sense.

There are multiple approaches to deal with updating the branches in the stack: updating each branch one by one or using --update-refs to do it in one go.

We can always update each branch individually—one by one—following the chain (e.g., by updating, pr-2 before pr-3 and pr-3 before pr-4):

• Using `git rebase <parent>` when the parent branch introduces changes unrelated to commits in our branch. This is the simplest case, and it is the same `rebase` you would do without dealing with stacked branches.

• Using `git rebase --onto <parent> <original parent>` in situations where the original parent branch gets merged. For example, if pr-1 gets merged into main, we want to change our pr-2 parent from pr-1 to main (`git rebase --onto main pr-1`).

(Please note that the examples above assume that you have currently checked out the branch you want to update.)

Depending on the situation, this might be a lot of work, since some manual steps are required to be done for each branch in the chain. I used both approaches in the past, and there is nothing wrong with them, especially if you manage one or two stacked branches.

The rebase --onto can also be useful when changing parents outside of stacked PRs (“take the last 2 commits and move them on top of feature-x” can be as simple as `git rebase --onto feature-x HEAD~2`).

Fortunately, Git makes it possible to directly update all branches in the stack by using rebase --update-refs. To use it:

• Check out the last branch in the chain, like pr-3

• Run rebase main --update-refs

If, for instance, the pr-1 branch is already merged into main, Git recognizes that and updates all references from pr-2 to main and pr-3 to the new pr-2. This makes it seamless to keep your stacked PRs in sync, although these steps don’t cover pushing the updated branches upstream. You will still have to do that yourself.

Happy stacking and have a nice weekend,

—Petr

• Jumping to the relative line (e.g., moving the cursor 5 lines above or below in the editor).

• Making a selection (e.g., select the 5 lines above or below the cursor).

Visual Studio Code supports working with line numbers only in a limited way, but it can be extended to support these operations.

The first step is to display the relative line numbers in the editor, which provides context for selecting the lines later on. This can be achieved by setting Editor: Line Numbers to relative in VSCode Settings for Text Editor (you can just open settings and type “line numbers”):

To have the same operations for jumping and selecting we will need to install an extension. I am using relative goto that provides exactly these two operations.

After installation I recommend to check or edit the keyboard shortcuts for these new operations. Alt + G (jump) and Alt + S (selection) should be the default:

Once done, these operations open a dialog where you can enter the desired relative line number, similar to Go to Line command for absolute numbers. Use minus (-) to select previous lines.

And that’s it! I use relative goto occasionally, but I’d prefer if there was native support instead. Do you use relative line numbers? Do you use any other extension? Let me know.

— Petr

Many programs can be configured via text files, but it can be annoying to remember where to find a particular config file or to repeatedly jump to a configuration file when testing changes. Programs like shells themselves, editors, locally installed databases and other utilities need to be (re)configured from time to time. Fortunately, shell aliases can help.

Let’s say you want to be able to quickly configure a text editor like Helix. To do so you will need to know the path to the config file (but you only have to look it up once!) and decide which program to use for editing it. In my case, I use Helix (abbreviated as hx) and the default helix configuration file is at ~/.config/helix/config.toml.Hence, the shell alias would look like this:

alias hxconf="hx ~/.config/helix/config.toml"

Such an alias will work in both Bash and Z shells (Zsh) and you only need to place it in the appropriate Bash/Zsh config file. For example, in the case of Z shell it is ~/.zshrc on Linux. In fact, I suggest that you create a zshconf or bashconf alias while you are at it.

It doesn’t matter whether you prefer to edit configuration files in the terminal, using VSCode, or need to open a different program altogether. In any case, opening the configuration directly from the command line is very convenient. I use config aliases for their ergonomics even though most configs I edit are in my separate dotfiles directory.

Some examples from my ~/.zshrc:

alias zshconf="hx ~/dotfiles/.zshrc"
alias starshipconf="hx ~/.config/starship.toml"
alias hxconf="hx ~/dotfiles/.config/helix/config.toml"
alias tmuxconf="hx ~/dotfiles/.tmux.conf"
alias gitconf="hx ~/dotfiles/.gitconfig"
alias pgservice="hx ~/dotfiles/.pg_service.conf"
alias pgpass="hx ~/dotfiles/.pgpass"
alias zellijconf="hx ~/dotfiles/.config/zellij/config.kdl"

Instead of invoking the editing program directly, you can also use $EDITOR if you have it set to the correct program. It will make the configuration more flexible when changing the default editor (unless you need a specific program for a particular conf file).

May your aliases serve you well,

Petr

While code coverage is certainly a useful metric to discover untested code, simply aiming for 100% of lines of code covered by tests is not a worthy goal in a test strategy on its own.

To demonstrate that, let’s start with a simple code example (it is valid Python but consider it to be just a pseudocode for the purpose of the demonstration to avoid discussing how such a function should be written in Python):

def is_even(number):
    if number % 2 == 0:
        return True
    else:
        return False

def test_is_even():
    assert is_even(2) == True
    assert is_even(3) == False

The code snippet is a function that should return True or False if the provided number is even or not, followed by a test for said function. After the test is executed the test runner will report 100% code coverage because all lines of code were touched during the test run:

---------- coverage -----------
Name               Stmts   Miss  Cover
--------------------------------------
test_coverage.py       7      0   100%
--------------------------------------
TOTAL                  7      0   100%

Unfortunately, 100% test coverage didn’t help us make sure our code or the tests were any good. The test is not testing whether the function returns correct results for all numbers nor it is testing if the function works with different data types or null values. And because the test doesn’t test things correctly, the function under test might be all wrong too.

There are other situations where the code coverage lies to us a little bit. For instance, a valid code path can be completely missed because multiple tests touch all lines of code, but some specific lines of code are not touched in the right order - missing an edge case.

We might also miss the forest for the trees with the focus on full code coverage. Even if the code and tests are correct from a code perspective, code coverage will never tell you if the program does what it should, based on functional and other requirements.

All in all, code coverage is a useful tool to uncover untested code (for instance, during a code review), but it doesn’t make any real guarantees about the tests and, therefore, the code under test as well. That’s why aiming for 100% code coverage might not be worth it: there are probably other things to prioritize over it.

Have a nice rest of the weekend,

Petr

Today, we will explore the ability to work with a terminal the same way as we would with an open file: by using it as an open editor, aka a tab:

By default, the integrated terminal is housed in a separate panel that can be opened with the command called View: Toggle Terminal (shortcut Ctrl + `). This allows you to use the terminal on the side (with the panel positioned to the top, bottom, left, or right of the editor).

There are, however, some advantages to using the terminal as an open editor. The first one is that it makes it easy to cycle through one or multiple terminals easily in the same way as we would with open files (and together with the open files). The second advantage is that it offers a little more space to see the output without the need to keep the panel maximized for other tasks.

Opening a new terminal as an open editor can be done with the command Terminal: New Terminal in Editor Area or its variation that can open the editor on the side of the current file.

We can also make this style the default by setting Terminal > Integrated > Default Location to editor. With this setting, a new terminal can be opened with the Terminal: Create New Terminal command directly (shortcut Ctrl + Shift + `).

Have a nice weekend,

Petr