On Mon, Dec 6, 2010 at 12:00 PM, Philip Ganchev <phil.ganc...@gmail.com> wrote: > On Sat, Dec 4, 2010 at 10:33 PM, Dylan Smith <dylan.ah.sm...@gmail.com> wrote: >> I thought a good test case for fish_indent was to try it on all the fish >> functions (i.e. share/functions/*.fish). I used the following command: >> >>> for f in *.fish; diff "$f" (../../fish_indent < "$f" | psub); end | vim -R - >> (Note: I used vim to show whitespace and for syntax highlighting) >> >> Here are my observations: >> >> In __fish_complete_ls.fish I found that "and" commands get split onto the >> next line: >> - command ls --version >/dev/null ^/dev/null; and set is_gnu --is-gnu >> + command ls --version > /dev/null ^ /dev/null >> + and set is_gnu --is-gnu >> A good heuristically for fish_indent would be to keep the "and" and "or" >> commands on the same line. Perhaps this will cause long lines in some >> cases, but if the "and" command gets split onto another line then perhaps >> it should be indented. > > Absolutely not! "and", "or" and "not" should go on separate lines. It > is easier to read code that has smaller chunks of code per line. The > traditional shell script mindset runs counter to that, but if you > change the mindset, it's all good. Fish is about doing the right thing > even if it means breaking with convention. Also, they are separate > commands, so there should be no exceptions for them compared to other > commands. That is the Law of Minimalism. >
No, I don't think so. I used to write code like "do_critical; or exit 1" ,in which case you see one line of code then you would know what it is doing. If I have to write do_critical or exit 1 then you will have to see tow lines to get the idea. And if you see a and/or command at the beginning, we will have to go back for a line and see what is doing there. Personally, I don't like that. >> Above you might also have noticed ^/dev/null get a space added between the >> redirection symbol and the filename. This frequently occurs, because it >> seems as if it is more common to omit the space, so should fish_indent be >> changed to omit this space? > > No. It is easier to read code that has tokens separated by spaces. You > can certainly find shell script code that omits the spaces before or > after the redirection symbols, but I think that's just sloppiness and > poor style; there is no good reason for it. > I think space is used to separate semantic blocks. There is a space before redirect symbol because the redirection is different form others. The reason that there is no space between redirect symbol and the file name is they are in the same semantic block, just like the leading minus sign of options. If they are separate, users have to look twice to confirm that the filename is where the output redirected to but not the file name parameter taken by the command. All of the above is just my personal taste. -- Cheers, Grissiom ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users