"if elif else"문이 사실상 테이블 형식이 아닌 이유는 무엇입니까?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

위의 예제를 감안할 때 코드 기반에서 첫 번째 스타일을 실제로 보지 못하는 이유를 이해하지 못합니다. 나에게 코드를 원하는 것을 명확하게 보여주는 표 형식으로 바꿉니다. 첫 번째 열은 사실상 무시할 수 있습니다. 두 번째 열은 조건을 식별하고 세 번째 열은 원하는 출력을 제공합니다. 적어도 나에게는 솔직하고 읽기 쉬운 것 같습니다. 그러나 나는 항상이 간단한 종류의 케이스 / 스위치 상황이 확장 된 탭 들여 쓰기 형식으로 나옵니다. 왜 그런 겁니까? 사람들이 두 번째 형식을 더 읽기 쉽게 찾습니까?

이것이 문제가 될 수있는 유일한 경우는 코드가 바뀌고 길어질 경우입니다. 이 경우 코드를 길고 들여 쓰기 된 형식으로 리팩터링하는 것이 합리적이라고 생각합니다. 그것이 항상 행해진 방식이기 때문에 모든 사람이 단순히 두 번째 방법을 사용합니까? 악마의 옹호자이기 때문에 다른 이유는 사람들이 if / else 문의 복잡성에 따라 혼란 스럽기 때문에 두 가지 형식을 찾는 것이 아닐까요? 모든 통찰력은 인정 될 것입니다.

한 가지 이유는 인기있는 언어를 사용하지 않기 때문일 수 있습니다.

몇 가지 반례 :

경비원과 패턴이있는 하스켈 :

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

패턴이있는 얼랭 :

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

이맥스 리스프 :

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

일반적으로 테이블 형식은 기능적 언어 (및 일반적인 표현 기반 언어)에서 널리 사용되는 반면 줄 바꿈은 다른 언어 (주로 문장 기반)에서 가장 인기가 있습니다.

더 읽기 쉽습니다. 몇 가지 이유 :

• 거의 모든 언어 가이 구문을 사용합니다 (모두는 아니지만 대부분 예제는 Python 인 것처럼 보입니다)
• isanae는 대부분의 디버거가 줄 기반 (문 기반이 아님) 이라는 의견에서 지적했습니다.
• 세미콜론이나 중괄호를 인라인 해야하는 경우 훨씬 더 추해지기 시작합니다.
• 더 순조롭게 읽는다
• 사소한 return 문 이외의 것이 있으면 끔찍하게 읽을 수없는 것처럼 보입니다 .
  • 조건부 코드가 더 이상 시각적으로 분리되어 있지 않기 때문에 코드를 훑어 보면 들여 쓰기로 의미있는 구문이 손실됩니다 ( Dan Neely ).
  • 1 행 if 문에 항목을 계속 패치 / 추가 할 경우 특히 나쁩니다.
• 모든 if 검사의 길이가 같은 경우에만 읽을 수 있습니다
• 여러 문장으로 진술, 그들은한다면 그것은 당신이 복잡한 포맷 할 수 없습니다 의미 가 oneliners로
• 여러 줄을 함께 구문 분석하지 않고 세로로 읽을 때 버그 / logicflow를 발견 할 가능성이 훨씬 큽니다.
• 우리의 뇌는 길고 가로 텍스트보다 더 좁고 큰 텍스트를 훨씬 빠르게 읽습니다.

이 작업을 수행하려고 시도하는 순간 여러 줄로 다시 작성하게됩니다. 그것은 당신이 시간을 낭비한다는 것을 의미합니다!

또한 사람들은 필연적으로 다음과 같은 것을 추가합니다.

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

이 형식이 다른 형식보다 훨씬 우수하다고 결정하기 전에이 작업을 자주 수행하지 않아도됩니다. 아,하지만 한 줄에 모두 인라인 할 수 있습니다! enderland는 내부에서 사망합니다 .

아니면 이거:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

정말 성가시다. 아무도 이와 같은 형식을 좋아하지 않습니다.

마지막으로, "탭을위한 공간이 얼마나 많은가"문제의 거룩한 전쟁을 시작할 것입니다. 표 형식으로 화면에 완벽하게 렌더링되는 것은 설정에 따라 광산에서 렌더링되지 않을 수 있습니다.

가독성은 IDE 설정에 의존해서는 안됩니다.

나는 '코드가 여러 번 읽히고 몇 번 작성되었으므로 가독성이 매우 중요합니다.'

다른 사람들의 코드를 읽을 때 도움이되는 핵심은 눈이 인식하도록 훈련 된 '정상적인'패턴을 따르는 것입니다. 들여 쓰기 된 양식을 너무 쉽게 보았 기 때문에 거의 자동으로 등록되기 때문에 들여 쓰기 된 양식을 가장 쉽게 읽을 수 있습니다. '더 예쁘기'때문이 아니라 내가 익숙한 규칙을 따르기 때문입니다. 컨벤션은 '더 나은'을 능가합니다 ...

이미 언급 한 다른 단점과 함께 테이블 형식 레이아웃은 수동 개입이 필요한 버전 제어 병합 충돌 가능성을 높입니다.

테이블로 정렬 된 코드 블록을 다시 정렬해야하는 경우 버전 제어 시스템은 각 행을 수정 된 것으로 간주합니다.

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

이제 다른 지점에서 프로그래머가 정렬 된 코드 블록에 새 줄을 추가했다고 가정합니다.

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

해당 브랜치 병합에 실패합니다 :

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

수정중인 코드가 테이블 정렬을 사용하지 않은 경우 병합은 자동으로 성공했을 것입니다.

(이 답변은 코드에서 테이블 형식 정렬을 권장하지 않는 내 기사 에서 "표절 화되었습니다" ).

일이 항상 할당 된 너비에 맞는 경우 표 형식이 매우 좋습니다. 그러나 할당 된 너비를 초과하는 항목이 있으면 나머지 테이블과 정렬되지 않은 테이블의 일부를 갖거나 긴 항목과 일치하도록 테이블의 다른 모든 레이아웃을 조정해야하는 경우가 종종 있습니다. .

소스 파일이 테이블 형식 데이터로 작동하도록 설계된 프로그램을 사용하여 편집되었고 더 작은 글꼴 크기를 사용하여 지나치게 긴 항목을 처리하고 동일한 셀 내에서 두 줄로 분할하는 등의 경우에는 테이블 형식을 사용하는 것이 좋습니다. 형식은 더 자주 지정되지만 대부분의 컴파일러는 형식을 유지하기 위해 이러한 편집기가 저장해야하는 종류의 마크 업이없는 소스 파일을 원합니다. 가변적 인 들여 쓰기가 있지만 다른 레이아웃이없는 행을 사용하는 것이 가장 좋은 경우 표 형식화만큼 좋지는 않지만 최악의 경우에는 거의 많은 문제가 발생하지 않습니다.

특별한 경우에 이런 종류의 것을 제공하는 '스위치'문이 있지만 그게 당신이 요구하는 것이 아니라고 생각합니다.

나는 테이블 형식의 if 문을 보았지만 그것을 가치있게 만들려면 많은 조건이 있어야합니다. 3 문장이 전통적인 형식으로 표시되는 것이 가장 좋지만 20을 가진 경우 문장을 명확하게 만들기 위해 큰 블록으로 표시하는 것이 훨씬 쉽습니다.

분명한 점이 있습니다. 보기가 더 쉬워지고 첫 번째 예제가 : 구분 기호가 어디에 있는지 쉽게 알 수 없다면 상황에 맞게 형식을 지정하십시오. 그렇지 않으면 사람들이 기대하는 것을 고수하면 항상 인식하기가 더 쉽습니다.

표현이 정말 쉬운 경우 대부분의 프로그래밍 언어는? : 분기 연산자를 제공합니다.

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

이것은 읽기 쉬운 짧은 표 형식입니다. 그러나 중요한 부분은 : "주요"행동이 무엇인지 한 눈에 알 수 있습니다. 이것은 답장입니다! 그리고 가치는 특정 조건에 의해 결정됩니다.

반면에 다른 코드를 실행하는 분기가있는 경우이 블록을 들여 쓰기가 훨씬 더 읽기 쉽습니다. 이제 if 문에 따라 다른 "주요"조치가 있습니다. 어떤 경우에는 던지고, 어떤 경우에는 기록하고 돌아 오거나 그냥 돌아옵니다. 로직에 따라 다른 프로그램 흐름이 있으므로 코드 블록은 다른 분기를 캡슐화하고 개발자에게 더 두드러지게 만듭니다 (예 : 프로그램 흐름을 파악하는 기능을 빠르게 읽는 기능)

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

enderland가 이미 말했듯이, 당신은 행동으로 하나의 "반환"만 있다고 가정하고 조건의 끝에 "반환"에 태그를 지정할 수 있습니다. 이것이 성공하지 못한 이유에 대해 좀 더 자세히 설명하고 싶습니다.

선호하는 언어가 무엇인지 모르겠지만 오랫동안 C로 코딩했습니다. 초기 코딩 또는 나중에 유지 보수 중 오류가 발생하기 쉬운 코드 구성을 허용하지 않음으로써 일부 표준 코딩 오류를 피하기위한 많은 코딩 표준이 있습니다. 저는 MISRA-C에 가장 익숙하지만 다른 언어도 있지만 일반적으로 같은 언어로 같은 문제를 해결하기 때문에 모두 비슷한 규칙을 가지고 있습니다.

코딩 표준이 종종 해결하는 하나의 인기있는 오류는 다음과 같은 작은 문제입니다.

if (x == 10)
    do_something();
    do_something_else();

이것은 당신이 생각하는 것을하지 않습니다. C와 관련하여 x가 10이면 x를 호출 do_something()하지만 x의 값에 관계없이do_something_else() 호출 됩니다. "if"문 바로 다음의 조치 만 조건부입니다. 이것은 코더가 의도 한 것일 수 있으며,이 경우 관리자에게 잠재적 인 함정이 있습니다. 또는 코더가 의도 한 것과 다를 수 있습니다.이 경우 버그가 있습니다. 인기있는 인터뷰 질문입니다.

코딩 표준의 솔루션은 모든 조건부 동작이 단일 행인 경우에도 중괄호를 의무화하는 것입니다. 우리는 지금 얻는다

if (x == 10)
{
    do_something();
    do_something_else();
}

또는

if (x == 10)
{
    do_something();
}
do_something_else();

이제는 올바르게 작동하며 관리자에게 명확합니다.

이것은 테이블 스타일 형식과 완전히 호환되지 않습니다.

다른 언어 (예 : Python)는이 문제를보고 코더가 공백을 사용하여 레이아웃을 명확하게하기 때문에 중괄호 대신 공백을 사용하는 것이 좋습니다. 파이썬에서

if x == 10:
    do_something()
    do_something_else()

x == 10에서 조건부 do_something()와 do_something_else()조건부 모두를 호출하는 반면

if x == 10:
    do_something()
do_something_else()

do_something()x 에만 조건부 do_something_else()이고 항상 호출 됨을 의미합니다 .

그것은 유효한 개념이며, 몇 가지 언어가 그것을 사용한다는 것을 알게 될 것입니다. (처음에는 Occam2에서 처음 보았습니다.) 다시 한 번, 테이블 스타일 형식이 언어와 호환되지 않는 것을 쉽게 알 수 있습니다.

표 레이아웃은 제한된 경우에 유용 할 수 있지만 if에 유용한 경우는 거의 없습니다.

간단한 경우? :가 더 나은 선택 일 수 있습니다. 중간 경우에는 스위치가 더 적합합니다 (언어가있는 경우). 복잡한 경우에는 호출 테이블이 더 적합하다는 것을 알 수 있습니다.

코드를 리팩토링 할 때 patern을 명확하게하기 위해 표 형식으로 재정렬 한 경우가 여러 번있었습니다. 대부분의 경우 일단 이해하면 문제를 해결하는 더 좋은 방법이 있다는 점에서 그런 식으로 남겨 두는 경우는 거의 없습니다. 때때로 코딩 관행이나 레이아웃 표준이이를 금지하며,이 경우 주석이 유용합니다.

에 대해 몇 가지 질문이있었습니다 ?:. 예, 삼항 연산자입니다 (또는 값을 생각하고 싶습니다). 처음에는이 예제가 약간 복잡합니다. 해결책.

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

테이블 형식에 문제가 없습니다. 개인 취향이지만 다음과 같이 삼항을 사용합니다.

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

return매번 반복 할 필요가 없습니다. :)