22

是否可以不在 Go 的标志包中设置默认值？例如，在 flag 包中，您可以写出以下行：

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

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

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

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

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

谢谢。

4

2 回答 2

22

I think it's idiomatic to design your flag values in such a way which implies "not present" when equal to the zero value of their respective types. For example:

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

Ad the 2nd question: IINM, the flag package by design doesn't distinguish between -flag and --flag. IOW, you can have both -f and --file in your flag set and write any version of - or -- before both f and file. However, considering another defined flag -g, the flag package will not recognize -gf foo as being equvalent of -g -f foo.

于 2013-08-25T14:25:15.010 回答
8

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

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

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

于 2013-08-25T17:45:39.897 回答