Go 中的标志包 - 我是否必须始终设置默认值？

Question

Go 中的 flag 包可以不设置默认值吗？例如，在 flag 包中可以写出以下行：

filename := flag.String("file", "test.csv", "Filename to cope with")

在上面的代码中，我不想设置默认值，在这种情况下是test.csv，而是总是让用户指定他们自己的文件名，如果没有指定，那么我想引起错误并退出程序。

我想出的一种方法是在执行flag.Parse() 之后首先检查filename 的值，如果该值是test.csv，那么我会让程序退出并显示相应的错误消息。但是，如果可以避免，我不想编写这样的冗余代码 - 即使它不能，我想在这里听到任何更好的方法来解决这个问题。

顺便说一句，您可以在 Python 的 argparse 模块中执行这些操作 - 如果可以的话，我只想实现类似的事情......

另外，我可以在标志包中同时实现短参数和长参数（换句话说，-f 和 -file 参数？）？

谢谢。

Answer 1

我认为以这样一种方式设计您的标志值是惯用的，当等于它们各自类型的零值时，这意味着“不存在”。例如：

optFile := flag.String("file", "", "Source file")
flag.Parse()
fn := *optFile
if fn == "" {
        fn = "/dev/stdin"
}
f, err := os.Open(fn)
...

第二个问题：IINM，标志包设计不区分-flag 和--flag。 IOW，您可以在标志集中同时设置-f 和--file，并在f 和file 之前写入- 或-- 的任何版本。但是，考虑到另一个已定义的标志 -g，标志包将不将 -gf foo 识别为等同于 -g -f foo。

Answer 2

当我有一个不能有默认值的标志时，我经常使用值REQUIRED 或类似的值。我发现这使--help 更易于阅读。

至于为什么它没有被烘烤，我怀疑它只是被认为不够重要。默认值并不适合所有需要。但是，--help 标志是相似的；它不能满足所有需求，但在大多数情况下已经足够了。

这并不是说所需的标志是一个坏主意。如果你足够热情，flagutil 包可能会很好。包装当前的flag api，使Parse 返回描述缺失标志的错误并添加RequiredInt 和RequiredIntVar 等。如果它被证明有用/流行，它可以与官方@987654329 合并@包。