Refactor '(default: …)' flag string into utility function #1080
Conversation
The usage of the `(default: …)` strings are a bit error prone so we now refactor them into a dedicated helper function. Signed-off-by: Sascha Grunert <sgrunert@suse.com>
saschagrunert
requested review from
coilysiren and
asahasrabuddhe
and removed request for
a team
Codecov Report
@@ Coverage Diff @@
## master #1080 +/- ##
==========================================
+ Coverage 72.91% 72.93% +0.02%
==========================================
Files 33 33
Lines 2481 2483 +2
==========================================
+ Hits 1809 1811 +2
Misses 565 565
Partials 107 107
Continue to review full report at Codecov.
|
| func formatDefault(format string) string { | ||
| return " (default: " + format + ")" | ||
| } |
There was a problem hiding this comment.
(non-blocking comment) do we know offhand why the different calls need different formatting verbs?
There was a problem hiding this comment.
Yeah we quote strings, but not bools for example. Because if the flag is a bool, then passing "true" will be interpreted as string and not bool.
Btw, I was wondering why we not print the default (like "" for string flags) values. 🤔
There was a problem hiding this comment.
I think not printing the zero value makes sense because it's not unlikely that an application has logic that treats the zero value as something other than "".
For example, I have a CLI app with several string flags, including --file <path> and --install-completion <shell-name>. The "default" value for the config file is actually to recursively search up directories until it finds a file with a matching name. An empty string isn't accurate in this case, but that's how my app sees it. For --install-completion, the options are bash or zsh, but if nothing is passed, the flag doesn't run.
An empty string in both of those cases means something to me as an application developer, but not to the consumers of my CLI application, so I like the current behavior.
What type of PR is this?
What this PR does / why we need it:
The usage of the
(default: …)strings are a bit error prone so we nowrefactor them into a dedicated helper function.
Which issue(s) this PR fixes:
None
Release Notes
(REQUIRED)