| Message ID | a45b646fced228e5a7fab4db7a35c1c6084e58d0.1538581868.git.matvore@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Clean up tests for test_cmp arg ordering and pipe placement | expand |
Matthew DeVore <matvore@google.com> writes: > Add the following guideline to Documentation/CodingGuidelines: > > &&, ||, and | should appear at the end of lines, not the > beginning, and the \ line continuation character should be > omitted "should be omitted" sounds as if it is the norm to have such a character, but it is not. The text in the actual patch body does a much better job than this. Perhaps Break overlong lines after "&&", "||", and "|", not before them; that way the command can continue to subsequent lines without backslash at the end. > And the following to t/README (since it is specific to writing tests): > > pipes and $(git ...) should be avoided when they swallow exit > codes of Git processes Good. > Signed-off-by: Matthew DeVore <matvore@google.com> > --- > Documentation/CodingGuidelines | 18 ++++++++++++++++++ > t/README | 28 ++++++++++++++++++++++++++++ > 2 files changed, 46 insertions(+) > > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines > index 48aa4edfb..72967deb7 100644 > --- a/Documentation/CodingGuidelines > +++ b/Documentation/CodingGuidelines > @@ -118,6 +118,24 @@ For shell scripts specifically (not exhaustive): > do this > fi > > + - If a command sequence joined with && or || or | spans multiple > + lines, put each command on a separate line and put && and || and | > + operators at the end of each line, rather than the start. This > + means you don't need to use \ to join lines, since the above > + operators imply the sequence isn't finished. Correct. Even though I wonder if we need to say the last sentence, which is rather obvious, patch is already written and I do not see much point editing this further. > + (incorrect) > + grep blob verify_pack_result \ > + | awk -f print_1.awk \ > + | sort >actual && > + ... > + > + (correct) > + grep blob verify_pack_result | > + awk -f print_1.awk | > + sort >actual && > + ... > + > - We prefer "test" over "[ ... ]". > > - We do not write the noiseword "function" in front of shell > diff --git a/t/README b/t/README > index 85024aba6..9a71d5732 100644 > --- a/t/README > +++ b/t/README > @@ -466,6 +466,34 @@ And here are the "don'ts:" > platform commands; just use '! cmd'. We are not in the business > of verifying that the world given to us sanely works. > > + - Don't use Git upstream in the non-final position in a piped chain, as > + in: "upstream in the non-final position" is a bit redundant, isn't it? - Don't feed the output of 'git' to a pipe, as in: > + > + git -C repo ls-files | > + xargs -n 1 basename | > + grep foo > + > + which will discard git's exit code and may mask a crash. In the > + above example, all exit codes are ignored except grep's. Good. > + Instead, write the output of that command to a temporary > + file with ">" or assign it to a variable with "x=$(git ...)" rather > + than pipe it. > + > + - Don't use command substitution in a way that discards git's exit > + code. When assigning to a variable, the exit code is not discarded, > + e.g.: > + > + x=$(git cat-file -p $sha) && > + ... > + > + is OK because a crash in "git cat-file" will cause the "&&" chain > + to fail, but: > + > + test "refs/heads/foo" = "$(git symbolic-ref HEAD)" > + > + is not OK and a crash in git could go undetected. Good. > - Don't use perl without spelling it as "$PERL_PATH". This is to help > our friends on Windows where the platform Perl often adds CR before > the end of line, and they bundle Git with a version of Perl that
On Fri, Oct 5, 2018 at 9:48 AM Junio C Hamano <gitster@pobox.com> wrote: > > Matthew DeVore <matvore@google.com> writes: > > > Add the following guideline to Documentation/CodingGuidelines: > > > > &&, ||, and | should appear at the end of lines, not the > > beginning, and the \ line continuation character should be > > omitted > > "should be omitted" sounds as if it is the norm to have such a > character, but it is not. The text in the actual patch body does a > much better job than this. > > Perhaps > > Break overlong lines after "&&", "||", and "|", not before > them; that way the command can continue to subsequent lines > without backslash at the end. That sounds good. Fixed. > > + - If a command sequence joined with && or || or | spans multiple > > + lines, put each command on a separate line and put && and || and | > > + operators at the end of each line, rather than the start. This > > + means you don't need to use \ to join lines, since the above > > + operators imply the sequence isn't finished. > > Correct. Even though I wonder if we need to say the last sentence, > which is rather obvious, patch is already written and I do not see > much point editing this further. ack > > @@ -466,6 +466,34 @@ And here are the "don'ts:" > > platform commands; just use '! cmd'. We are not in the business > > of verifying that the world given to us sanely works. > > > > + - Don't use Git upstream in the non-final position in a piped chain, as > > + in: > > "upstream in the non-final position" is a bit redundant, isn't it? > > - Don't feed the output of 'git' to a pipe, as in: Done, but I changed it to "Don't feed the output of a git command to a pipe, as in:" since referring to it as "git command" without the quotes seems rather common in this file. Thank you for the review!
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 48aa4edfb..72967deb7 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -118,6 +118,24 @@ For shell scripts specifically (not exhaustive): do this fi + - If a command sequence joined with && or || or | spans multiple + lines, put each command on a separate line and put && and || and | + operators at the end of each line, rather than the start. This + means you don't need to use \ to join lines, since the above + operators imply the sequence isn't finished. + + (incorrect) + grep blob verify_pack_result \ + | awk -f print_1.awk \ + | sort >actual && + ... + + (correct) + grep blob verify_pack_result | + awk -f print_1.awk | + sort >actual && + ... + - We prefer "test" over "[ ... ]". - We do not write the noiseword "function" in front of shell diff --git a/t/README b/t/README index 85024aba6..9a71d5732 100644 --- a/t/README +++ b/t/README @@ -466,6 +466,34 @@ And here are the "don'ts:" platform commands; just use '! cmd'. We are not in the business of verifying that the world given to us sanely works. + - Don't use Git upstream in the non-final position in a piped chain, as + in: + + git -C repo ls-files | + xargs -n 1 basename | + grep foo + + which will discard git's exit code and may mask a crash. In the + above example, all exit codes are ignored except grep's. + + Instead, write the output of that command to a temporary + file with ">" or assign it to a variable with "x=$(git ...)" rather + than pipe it. + + - Don't use command substitution in a way that discards git's exit + code. When assigning to a variable, the exit code is not discarded, + e.g.: + + x=$(git cat-file -p $sha) && + ... + + is OK because a crash in "git cat-file" will cause the "&&" chain + to fail, but: + + test "refs/heads/foo" = "$(git symbolic-ref HEAD)" + + is not OK and a crash in git could go undetected. + - Don't use perl without spelling it as "$PERL_PATH". This is to help our friends on Windows where the platform Perl often adds CR before the end of line, and they bundle Git with a version of Perl that
Add the following guideline to Documentation/CodingGuidelines: &&, ||, and | should appear at the end of lines, not the beginning, and the \ line continuation character should be omitted And the following to t/README (since it is specific to writing tests): pipes and $(git ...) should be avoided when they swallow exit codes of Git processes Signed-off-by: Matthew DeVore <matvore@google.com> --- Documentation/CodingGuidelines | 18 ++++++++++++++++++ t/README | 28 ++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+)