# Zhe Lu

Published articles for Zhe Lu.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Set Safe Defaults for Flags

DevFeed: [Set Safe Defaults for Flags](<https://devfeed.tech/articles/set-safe-defaults-for-flags-23866.md>)

Original publisher: [Read original article](<http://testing.googleblog.com/2026/03/set-safe-defaults-for-flags.html>)

Author: Google Testing Bloggers (noreply@blogger.com)

Published: 2026-03-03T14:47:00Z

Content type: article

Language: en

Sources: [Google Testing Blog](<https://devfeed.tech/sources/google-testing-blog.md>)

Topics: [Command-line interface](<https://devfeed.tech/topics/cli.md>), [Utility Software](<https://devfeed.tech/topics/utility.md>), [data](<https://devfeed.tech/topics/data.md>), [Shell](<https://devfeed.tech/topics/shell.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [command-line](<https://devfeed.tech/tags/command-line.md>), [commands](<https://devfeed.tech/tags/commands.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [google](<https://devfeed.tech/tags/google.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [safety](<https://devfeed.tech/tags/safety.md>), [tott](<https://devfeed.tech/tags/tott.md>), [zhe-lu](<https://devfeed.tech/tags/zhe-lu.md>)

### AI overview

This article explains how to choose safe defaults for command-line flags so that mistakes are less likely to cause harmful changes. It recommends strategies such as defaulting to dry runs, requiring confirmation for irreversible actions, and writing documentation commands with safer behavior.

### Source excerpt

This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Zhe Lu We all make mistakes. But big mistakes can cause big headaches! Suppose you're writing a utility to update production data for a launch. Before making changes to production data, you want to perform a dry run to validate the expected changes. In your excitement, you forget to include the --dry_run flag in your command: $ /scripts/credit_accounts --amount=USD10 # Oops, I forgot to include --dry_run You realize your mistake too late. Safe flag defaults can prevent a simple mistake from turning into a major outage: Flag has unsafe default: cliArgs.addBoolFlag(name="dry_run", default=False, help="If set, print change summary, but do NOT change data.") Flag has safe default: cliArgs.addBoolFlag(name="dry_run", default=True, help="If set, print change summary, but do NOT change data.") Safety depends on context: When defining flags, choose the default that minimizes the cost of potential mistakes. This might involve defaulting to a "dry" run, asking for user confirmation before irreversible actions, requiring a confirmation flag on the command line, or other strategies. If you're writing documentation that contains commands, always set values to minimize the damage if run blindly: Flag in documentation has unsafe default: ## How to commit changes Use this command to commit changes. Use --dry_run to test and compute and report changes. ```shell /scripts/credit_accounts --amount=[value] --filter=[conditions] ``` Flag in documentation has safe default: ## How to commit changes Use this command to compute and report changes. Use --nodry_run to commit the changes. ```shell /scripts/credit_accounts --amount=[value] --filter=[conditions] ``` Similarly, consider requiring that environment-specific flags (e.g., backend addresses and output folders) be explicitly set. In this situation, unspecified environme