Cli flag hierarchy and how to deal with it in code.

<p>I believe the title is self explanatory but I&#39;ll elaborate. The best description I can give is using an example ; so let me use the Linux &#34;find&#34; command. For basic searches by name I can simply use - &#34;find . -name &#34;*mp4&#34; &#34;. However, there are numerous other flags I can optionally include. For example the -depth flag. </p> <p>Programmatically how do you deal with optional flags and especially optional flags with hierarchical dependencies. </p> <p>I hope I&#39;m being clear enough. Is this a matter of clever switch statement use, combined with if/else blocks. On its face it doesn&#39;t seem that simple.</p> <hr/>**评论：**<br/><br/>porkbonk: <pre><p>First, every flag should have a sane default value.</p> <p>What exactly do you mean by hierarchical? Do you have a more specific example?</p> <p>What are you using to parse flags? Have you actually tried it with the flag package?</p></pre>ops-man: <pre><p>I&#39;m using the flags package. The parsing of the flags is not the problem. The problem is or seems more of a algorithmic nature.</p> <p>I guess what I am asking is how do you code the logic for all your flags. Even while using a Switch statement to code the logic some flags use defaults, some not, do this if flag A is default and flag B is default, this if A has value set and B is default, and C is set,else if C is default and A is default but B is set do this. </p> <p>The logic gets confusing with any non-trivial cli application. How do you handle such decision making. Just using some switch and if/else statements is gonna make for some ugly hard to follow code - right? </p></pre>faiface: <pre><p>I don&#39;t think there&#39;s any direct help here ;). It&#39;s simply an algorithmic problem, you have to figure it out for your specific case.</p> <p>For example, with the depth flag, you can give it a default value of -1 (which would mean infinity) and then your directory traversing logic would always only go to a certain depth and -1 would be the special case.</p> <p>It&#39;s usually possible to figure it out so that no nested switch statements are needed. Just choose correct default values and do your algorithms in such a way that default values do the right thing I guess.</p></pre>ops-man: <pre><p>OK. That makes me a little more confident about the direction I&#39;m moving in. So your telling me the logistical starting point should begin where all flags are their respective defaults and I should steer any decision making from changes to that norm. </p></pre>faiface: <pre><p>Basically. The flags should just naturally alter the flow of your algorithm.</p> <p>Also, I&#39;d suggest you don&#39;t use global variable flags, it&#39;s still better to pass their values (or values calculated from them) as arguments.</p></pre>shovelpost: <pre><p>One thing that you need to understand when working with the <code>flags</code> package, is that it was not meant to replicate the GNU flags and it was coded after an existing google library (I believe <a href="https://gflags.github.io/gflags/" rel="nofollow">this</a> is it).</p> <p>Therefore if you try to emulate some GNU flags functionality like short flag aliases then you will need extra effort and start wondering why flags doesn&#39;t give you an easy way to do it.</p> <p>My advice is to use only the absolutely required flags, avoid subcommands and do not try to emulate GNU flags functionality. In general, keep it simple.</p> <p>If your problem domain really requires complex flags then you have to deal with it and program a solution. Also you can can always have a look at how the Go team has created the commands of the go tooling to get some inspiration.</p></pre>ops-man: <pre><p>Thanks. I believe a good look at the go tool itself may indeed help me out. I should&#39;ve thought of that right away. </p></pre>porkbonk: <pre><p>I agree. <em>KISS</em> and try to stick with <code>flag</code> if you can. Remember that you can use multiple FlagSets, e.g. a common one and then one for each sub-command.</p> <p>There&#39;s also quite a few alternative parsing libs that are more powerful, but a bit more verbose.</p> <p>Perhaps have a look around here to get inspired: <a href="https://github.com/avelino/awesome-go#standard-cli" rel="nofollow">https://github.com/avelino/awesome-go#standard-cli</a></p></pre>