“for”와 같은 줄에“do”를 배치해야하는 이유는 무엇입니까?

1. 요약

이해가 안되는데 왜 E010 bashate rule이 필요한 가요 ?

2. 세부 사항

린트 파일 에는 bashate 를 사용 .sh합니다. E010 규칙 :

이렇게 같은 줄에하지 에 대한

for bashate :

• 옳은:

  #!/bin/bash
  for f in bash/*.sh; do
      sashacommand "$f"
  done

• 오류:

  #!/bin/bash
  for f in bash/*.sh
      do sashacommand "$f"
  done

유효한 논쟁이 필요한 이유는 무엇 for이며 do같은 줄에 있습니까?

3. 유용하지 않다

내 질문에 대한 답변을 찾을 수 없습니다 :

1. 구글
2. 최상의 코딩 방법에 관한 기사 ( 예 )

3. bashate 문서 . 나는 단지 찾는다:

   제어 블록에서 일관된 상태를 유지하는 데 도움이되는 일련의 규칙. 롤링은 "흥미로운"종류이기 때문에 계속되는 긴 줄에서는 무시됩니다.

문법적으로, 다음 두 코드 스 니펫은 정확하고 동등합니다.

for f in bash/*.sh; do
    sashacommand "$f"
done

for f in bash/*.sh
    do sashacommand "$f"
done

후자는 수있는 가능성 으로 읽기 어렵게라고 할 do약간 루프 본체에서 명령을 난독. 루프에 여러 명령이 포함되어 있고 다음 명령이 새 행에 있으면 난독 화가 더 강조 표시됩니다.

for f in *
    do cmd1
    cmd2
done

...하지만 "오류"로 표시하는 것은 객관적인 진실보다는 누군가의 개인적인 의견입니다.

일반적으로 거의 모든 ;것이 개행으로 대체 될 수 있습니다. 모두 ;와 줄 바꿈 명령 터미네이터이다. do"이 for루프 에서 수행해야 할 사항을 따릅니다"라는 의미의 키워드입니다 .

for f in *; do ...; done

와 같다

for f in *
do
   ...
done

그리고

for f in *; do
   ...
done

서로를 사용하는 이유는 가독성과 지역 / 개인 스타일 규칙 때문입니다.

개인적인 의견 :

매우 긴 루프 헤더에서는 다음 do과 같이 새 줄을 작성하는 것이 합리적이라고 생각합니다 .

for i in animals people houses thoughts basketballs bees
do
    ...
done

또는

for i in        \
    animals     \
    people      \
    houses      \
    thoughts    \
    basketballs \
    bees
do
    ...
done

성명서 then에서도 마찬가지 if입니다.

그러나 이것은 다시 개인 스타일 선호도 또는 팀 / 프로젝트가 사용하는 코딩 스타일에 달려 있습니다.

페이지 상단에 표시된 내용을 참고하십시오.

bashate : bash 스크립트와 동등한 pep8

PEP8 은 Python 코드 용 스타일 가이드입니다. 파이썬 사람들은 종종 자신의 스타일 문제를 매우 진지하게 생각하는 것처럼 보이지만 ^{[인용이 필요합니다]} , 그것은 단지 가이드 일뿐입니다. 우리는와 do같은 줄 for에 넣는 것과 그것의 줄에 넣는 것에 대해 거꾸로 할 수있었습니다 .

또는 블록 (또는 그와 같은)을 {시작할 때 C 코드 를 어디에 넣을 것인지와 같은 토론 입니다.ifwhile

문서의 아래 몇 줄에는 또 다른 흥미로운 규칙이 있습니다.

E020 : 함수 선언이 형식이 아님 ^function name {$

여기서 중요한 점은 해당 스타일 가이드의 저자가 function독자가 함수 선언을 인식하기 위해 키워드를 사용해야 한다고 생각한다고 가정합니다 . 그러나, function fooA는 비 - 표준 기능을 정의하는 방법은 다음 표준 방법이다 foo(). 두 가지 (Bash)의 유일한 차이점은 /bin/shDebian 또는 Ubuntu 와 같이 다른 하나는 표준 쉘로 포팅하기가 어렵다는 것 입니다.

그래서, 나는 모든 스타일 가이드를 소금 또는 3 알갱이로 가져 와서 최고의 스타일이 무엇인지 스스로 결정하는 것이 좋습니다. 좋은 스타일 검사기를 사용하면 일부 검사를 비활성화 할 수 있습니다 (수신자가 bashate -i E010,E011두 가지 검사를 무시해야 함). 우수한 스타일 검사기는 예를 들어 E020의 반대를 확인하는 등 테스트를 수정할 수 있습니다.

TL; DR : 필요하지 않습니다. 그냥 친구의 의견 일뿐입니다.

다른 많은 사람들처럼, 나는 for수십 년 동안 이와 같은 루프를 작성해 왔습니다.

for F in arg1 arg2 arg*
do
    somecommand "$F"
done

이 레이아웃 do ... done은 C와 같은 언어의 중괄호와 같이 루프 본문 을 둘러싼 사실을 강조하고 개행을 통해 루프 구성 요소를 분리 할 수 ​​있습니다.

물론 중괄호를 어디에 배치해야하는지에 대한 종교적인 전쟁이 있기 때문에 배심원 단이 아직이 중 하나라고 말할 수도 있습니다. IMHO, 이것이 분명히 작동하도록 설계된 방식입니다. Bourne은 일치하는 구분 기호를 좋아했습니다. if ... fi,, case ... esac짧은 버전의 세미콜론이 필요하다는 것은 원래 설계된 것보다 더 짧게 만들고 있음을 나타냅니다. 아무 문제가 없습니다. 기술 발전과 한때 좋은 생각처럼 보였던 많은 것들이 이제는 눈살을 찌푸리고 goto있습니다. 그러나 전체 쉘 스크립팅 커뮤니티가 bashate저자 의 선호를 채택 할 때까지는 별도의 조치를 취할 필요가 없습니다.

아무도이 유효하고 이식 가능한 구문을 아직 언급하지 않은 것에 놀랐습니다.

set alfa bravo charlie
for q do
  echo "$q"
done

조심스럽게 주목 그 for와 do세미콜론없이, 같은 줄에 있습니다. 결과:

alfa
bravo
charlie

여기에 몇 가지 좋은 답변이 있습니다. 항상 소금 한 알과 함께 스타일 가이드를 가져오고 IMHO와 경험은 스타일에 관해서 과도한 교리가있는 지역 사회에 대해 항상 약간 걱정해야합니다. 마치 내가 마지막으로 점을 찍었을 때 마지막 T가 넘어지면 소프트웨어가 작동한다고 믿는 것과 거의 같습니다. 때로는 버그를 제거하는 데 완벽한 스타일 이상의 것이 필요합니다 ...

쉘을 배우기 시작할 때 대부분의 스크립트와 튜 트는 인라인 세미콜론 형식을 사용했습니다.

for i in "$@"; do
    stuff
done

그러나 나는 경험이 없었기 때문에 조금 힘든 시간을 보냈습니다. 그리고 구문 정확성을 확인하는 데 필수적입니다. 그래서 나는 다음 줄에서 그 일을 스스로 선호했습니다. 더 이상 그렇게하지 않습니다

또한 'while'명령은 멋진 작은 트릭을위한 훌륭한 후보입니다.

while prep1; prep2; condition; do
    stuff
done

그러나 prep 명령이 약간 부피가 크거나 조건이 복잡한 경우 다음과 같이 형식화하는 것이 좋습니다.

while
    prep1
    prep2
    condition
do
    stuff
done

그런 다음 do를 "; do"로 추가하는 것은 긍정적입니다.

그보다 더 강렬해질 수도 있습니다.

while
    if con1; then
      cond2
    elif cond3; then
      cond4
    elif cond5; then
      cond6
    else
      cond7
    fi
do
    stuff
done

모든 진술은 표현이기 때문입니다. 두 스타일이 어떻게 기회 적으로 사용되는지 주목하십시오. 깨끗하게 유지하고 읽을 수 있습니다. 스타일이나 "공간 절약"이라는 이름으로 압축하거나 뒤 틀리면 끔찍한 혼란이됩니다.

그래서! 일반적으로 쉘 스크립트의 바로크 스타일을 고려할 때 선명도를 높이고 중요한 기호에 쉽게 시각적으로 액세스하는 것을 목표로하는 것은 항상 좋은 것입니다.

'do'가 명령과 함께 인라인으로 작성된 형식은 약간의 명령이있을 때 달콤합니다 .'do '가 시각적으로 숨겨져 있거나 내부 명령이 실제로 모호하지 않습니다.

for i in whatever
  do stuff
done

나는 그것을 보는 것이 매우 즐겁다는 것을 알았습니다.

while condition
  do stuff
end

if condition
  then stuff1
  else stuff2
fi

case $blah in
  a) stuff1;;
  b) stuff2;;
  c) stuff3;;
  *) stuffInfinity;;
esac

명쾌하고 일반적인 정직함은 Codd *가 요구하는 모든 것입니다.

* 관계형 데이터베이스 이론의 아버지 인 Edgar F. Codd