단순성이 항상 가독성을 향상 시킵니까?

최근에 저는 회사의 코딩 표준 세트를 개발하고있었습니다. (우리는 회사의 새로운 언어로 분기하는 새로운 팀입니다.)

첫 번째 초안에서 코딩 표준의 목적을 가독성, 유지 관리 성, 신뢰성 및 성능 향상으로 설정했습니다. (쓰기, 이식성, 비용, 이전 표준과의 호환성 등을 무시했습니다.)

이 문서를 작성하는 동안 나의 목표 중 하나는 코드의 단순성이라는 아이디어를 추진하는 것이 었습니다. 한 줄에 함수 호출 또는 작업이 하나만 있어야한다는 아이디어가있었습니다. 나는 이것이 가독성을 높이기를 희망했다. 내가 이전 언어에서 이어받은 아이디어입니다.

그러나 나는이 추진의 배후에있는 가정에 의문을 제기했다.

단순성이 항상 가독성을 향상 시킵니까?

간단한 코드를 작성하면 가독성이 떨어지는 경우가 있습니까?

당연히 "단순하다"라는 말은 "쓰기가 더 쉽다"는 말이 아니라 한 줄에 더 적은 내용이 들어가는 것을 의미합니다.

"간단한"은 과용 된 단어입니다. "판독 가능"은 "간단한 이해"로 수익성있게 정의 할 수 있는데,이 경우 정의에 의해 단순성이 증가하면 가독성이 증가하지만 이것이 당신이 의미하는 것은 아니라고 생각합니다. 나는 이것 에 대해 다른 곳 에서 글을 썼지 만 일반적으로 더 추상적이거나 (더 적은 개념이 더 많은 현상을 표현할 수 있음) 더 구체적이어서 (이 경우 개념이 많은 배경을 필요로하지 않음) 무언가를 "더 단순"하다고 할 수있다 처음부터 이해할 지식). 나는 원근법에 따라보다 추상적 인 개념은보다 구체적인 개념보다 더 단순하게, 또는 그 반대 라고 합리적으로 주장 할 수있다 . "추상"과 "

필자는 얼마 전에 작성한 일부 Haskell 코드를 예로 사용하겠습니다. 나는 유래에 질문을 각 숫자가 다른 기본을 가질 수있는 카운터를 계산하기 위해 목록 모나드를 사용하는 방법에 대해. 내 최종 솔루션 (많은 Haskell을 모르는)은 다음과 같습니다.

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

답변 중 하나가 이것을 다음으로 줄였습니다.

count = mapM (enumFromTo 0)

이들 중 어느 것이 "간단하게"이해하기 쉬운가 (즉, 더 읽기 쉬운) 독자가 (절대적인) 모나 딕 연산 (그리고 그 문제에 대해 포인트없는 코드)을 얼마나 편안하게 사용했는지에 달려 있습니다. 이러한 추상 개념에 매우 익숙한 독자는 (짧은) 더 추상적 인 버전을 읽는 것을 선호 할 것이며, 그러한 작업에 익숙하지 않은 독자는 (긴) 더 구체적인 버전을 읽는 것을 선호 할 것입니다. 어느 버전이 더 읽기 쉬운 지에 대한 답은 없습니다.

코딩 표준이 "가독성, 유지 관리 성, 신뢰성 및 성능"에 관한 것이라면 다음 과 같이 기술하십시오 .

항상 반대의 예가있는 상황이있을 수 있으므로 이러한 것들을 달성하는 방법을 시도하고 처방하지 마십시오.

처방해야 할 것은 코드를 준수하지 않으면 코드가 손상되는 것입니다. 양식 적 특성은 코드를 위반하지 않으며 제안 사항이어야합니다 (팀의 대다수가 가독성이라는 것에 동의하는 한 나머지는 개발자가 선호해야 함 (코드 검토를 통해 다른 사람들이 코드를 읽을 필요가 있음을 사람들에게 상기시켜줍니다)) .

적은 "라인 당 항목", 단순성 및 가독성은 동일하지 않습니다. 문서화되지 않은 엄청나게 복잡한 알고리즘을 사용하여 2 개가 아닌 한 줄에 1 개의 문장으로 코딩 할 수 있으며, 훨씬 더 읽기 쉽지 않습니다.

또한 "줄당 항목 수"가 적 으면 개발자에게 큰 대형 모니터를 제공하여 코드 블록이 더 수직으로 확산되는 것을 볼 수 있습니다. 또는 더 작은 글꼴을 읽을 때 눈이 피로 해집니다.

가독성은 매우 고유 한 메트릭으로, 더 쉽게 측정 할 수있는 다른 여러 메트릭간에 타협이 필요합니다. 다른 모든 메트릭을 미리 제한하면 더 이상 타협이 불가능 해져 코드를 읽을 수 없게됩니다.

항상? - 아니

아이러니하게도 올바른 수준의 단순성을 얻는 것은 복잡한 일이 될 수 있습니다. 열쇠가 적당하다고 생각합니다. 단순함은 또한 보는 사람의 눈에있을 수 있으므로, 너무 많이 생각하면 혼자 내버려 두거나 나중에 다시 오십시오.

개인적으로 돌아가서 내가 쓴 것을 단순화하려고 할 때, 나는 마음을 바꾸거나 원하는 것을 얻기 위해 몇 가지 일을 시도한 영역에 중점을 둡니다. 이러한 영역은 일반적으로 부드럽게 처리 될 수 있습니다. 그런 다음 코드를 통해 몇 번의 통과를 수행하여 사물을 너무 많이 퍼 뜨리지 않고 더 읽기 쉽도록 디버그하여 무슨 일이 일어나고 있는지 파악하십시오.

간단하게 사용하면 다음과 같은 코드를 작성할 수 있습니다.

10000000000000000000000000000000000000000000

그러나 가독성을 원한다면 이것을 선호합니다.

1e43

반면에 항상 과학적 표기법으로 숫자를 다루지 않는 한 1000훨씬 읽기 쉽고 간단 1e3합니다.

이것은 거의 모든 곳에서 찾을 수있는 훨씬 일반적인 패턴의 변형 된 예입니다. 아주 간단한 블록으로 무언가를 만들면 다양한 방식으로 읽을 수없고 비효율적이거나 나빠질 수 있습니다. 반면에 일반화하고 재사용하는 것은 처음에는 어렵습니다 ( "wtf는 e?!는 쓰려고 1343했습니까?"라고 말할 수 있음). 그러나 장기적으로 많은 도움이 될 수 있습니다.

반드시 그런 것은 아닙니다. 복잡한 작업이 있다면 그 복잡성은 어딘가로 가야합니다. 한 줄에 들어가는 "재료"의 수를 줄이면 더 많은 줄이 필요하다는 것을 의미합니다. 루틴이 한 화면에 맞지 않을 때 코드 가독성을 떨어 뜨리는 경우 실제로는 코드 가독성에 해로울 수 있습니다.

명확성 + 표준 + 코드 재사용 + 좋은 설명 + 좋은 디자인 은 가독성을 향상시킬 수 있습니다.

알고리즘의 특성과 오늘날 응용 프로그램 구조의 복잡성 때문에 단순성이 개발자의 손에 항상 맞는 것은 아닙니다.

간단한 작업을 수행하는 간단한 웹 페이지를 가져옵니다. 정렬 루틴이 주어지면 논리를 단순화 할 수 없지만 의미있는 변수 이름을 사용하거나 구조적 방식으로 작성하는 등 주석으로 명확하게 만들 수 있습니다.

단순성이 항상 가독성을 향상 시킵니까?

아니요. 한 줄에 여러 간단한 작업을 수행하는 것이 여러 줄을 갖는 것보다 덜 복잡한 경우를 많이 보았습니다.

적은 코드와 간단한 코드 사이에는 트레이드 오프가 있습니다.

일반적으로 더 적은 줄로 코드를 작성하는 것이 더 낫지 않다면 더 간단한 코드를 사용하는 것이 좋습니다. "너무 복잡한"코드보다 "너무 자세한"코드를 사용하는 것이 좋습니다.

"가급적 단순하지만 간단하게 만들지 말 것" -Albert Einstein의 종종 역설

단순성으로 모든 것이 향상됩니다 . 물론 단순성의 다른 가치를 위해. 코드 줄이 적습니까? 아마도. 더 작은 실행 파일입니까? 혹시. 팀이 동의해야 할 내용입니까? 물론 입니다.

단순성이 항상 가독성을 향상 시킵니까? 예. 한 줄에 한 문장이 항상 더 간단합니까? 아닙니다. 상당수의 언어에는 3 진 연산자가 있으며, 한 번 파악하면 동등한 if / else 대입보다 더 간단하고 이해하기 쉽습니다.

한 줄에 여러 변수를 설정할 수있는 언어의 경우, 이에 상응하는 것보다 훨씬 간단하고 이해하기 쉽습니다.

또 다른 예 : 정규 표현식은 일반적으로 한 줄로 많은 작업을 수행하며 정규 표현식이없는 해당 표현식은 읽기가 훨씬 더 어렵습니다. / \ d {3} [-] \ d {3}-\ d {4} /는 최소한 몇 개의 주석이있는 함수 호출과 동일하며 해당 함수 본문보다 이해하기 쉽습니다.

가독성과 단순성은 주관적인 용어로, 사람과 상황에 따라 다르지만 항상 함께 사용되는 것은 아닙니다.

보다 객관적인 용어는 간결함입니다. 원칙적으로 캐릭터를 세어 계산할 수 있지만, 몇 가지 결함이 있습니다. 간결함은 단순성과 가독성을 암시하는 것처럼 보이지만 (적어도 제 생각에는) 예외가 있습니다.

의도가 더 잘 표현되면 더 길고 (더 복잡한 것은 더 복잡한) 코드를 더 쉽게 읽을 수 있습니다. 단순성에 대한 정의가 의도에 관심이 있는지 여부는 또 다른 주관적인 것입니다. 예를 들어, 의도를 전혀 언급하지 않고 구문 구조와 정보 이론 엔트로피 측면에서 복잡성을 정의 할 수 있습니다.

따라서 잘 선택된 더 긴 변수 이름은 ...

• 의도를보다 잘 표현하여 가독성 향상
• 간결함 감소-결국 더 길다
• 구문의 단순성에는 전혀 영향을 미치지 않습니다. 코드의 구문 구조는 변하지 않습니다.

마찬가지로을 쓸 수도 있습니다 if (some_boolean == true). 동등한 대안과 비교할 때 if (some_boolean), 이것은 ...

• 간결함 감소
• 구문의 단순성을 줄이지 만
• 의도를 더 잘 표현하여 가독성을 향상시킬 수 있습니다.

물론 이것은 많은 사람들에게 대량 항의를 불러 일으킬 것입니다-많은 사람들에게 이것은 항상 가독성을 손상시킵니다. 나에게 그것은 부울의 소스에 많이 의존합니다. 예를 들어 변수 이름 (또는 메소드 이름 또는 기타)은 값이 "진실 값"임을 명확하게 표현하지 못할 수 있습니다. 물론if 당신에게 무언가를 말해 주지만 여전히 냄새가납니다. 그러나 이것을 믿는 많은 사람들이 나를 바보라고 부를 것입니다.

물론 전체 주관성에 대한 추가 증거입니다.

몇 가지 기본 정의가 누락되었습니다 . 루트 심플 렉스에서 단순함 은 하나의 접힘을 의미 합니다 . 단순한 것은 한 가지 일을하는 것을 의미 합니다. 근본 용이성 에서 쉽게 , 근처에 거짓말을 의미 합니다 . 쉬운 것은 가까이에 있음을 의미합니다 . 간단한 예다른 답변에 제공된 코드 정확하게 나타나지 않습니다.

rotsor의 매우 큰 값을 표시 하십시오 . 그는 이것이 간단 하다고 말한다 . 내 생각에 간단하지 않습니다. 그것은 간단합니다. 필요한 0의 수를 입력하는 것은 가까이에 있습니다.

10000000000000000000000000000000000000000000

읽을 수있는 버전은 간단합니다. 한 가지 일을합니다. 이 함수를 위해 작성된 표기법 목적으로 크기를 설명하여 숫자를 표현합니다.

1e43

Aidan의 "간단한"코드 스 니펫을 한 가지로 설명 할 수 있습니까? 여기에는 10 줄의 코드 (댓글을 세지 않고)와 7 개 이상의 블록이 포함되어 있습니다 (내가 계산할 때). 당신이 의견을 따르면, 당신은 그것이 적어도 4 가지 일을하는 것을 보게 될 것입니다!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

그러나이 코드를 다시 작성하기위한 권장 사항 중 하나는 하나의 진술이었습니다. 아이 단은 독자가 모나 딕 문장, 포인터 프리 코드 등에 익숙하거나 익숙해 져야한다고 말합니다. 이러한 개념은 단일하고 배우기 위해 독립적입니다.

count = mapM (enumFromTo 0)

실제로 간단한 코드는 한 가지만 수행하기 때문에 쉬운 코드 보다 더 읽기 쉽습니다 . 간단한 코드 를 이해 하기 위해 더 많은 "한 가지"를 배워야 할 수도 있습니다 . 그러나 항상 더 읽기 쉬워야합니다.

단순성이 항상 가독성을 향상 시킵니까?

나는 아마도 약간의 논쟁으로, 절대로 그렇지 않다고 말할 것이다 .

퍼블릭 인터페이스에서 200 개의 멤버 함수를 가진 클래스를 나에게 전달할 수 있으며, 가장 인간이 읽을 수있는 퍼블릭 인터페이스 일 수 있습니다. 그러한 코드와 그 문서를 우연히 읽는 것은 기쁨 일 것입니다. 그러나 가독성에도 불구하고 이러한 함수가 서로 상호 작용하는 방식에 관심이 있고 오용으로 인해 까다로운 에지 사례를 조심해야하기 때문에 "간단한"이라고 부르지 않습니다.

사람의 실수를 방지하고 코드의 유지 관리 성을 향상시키는 측면에서 "가독성"이 가장 중요하지 않기 때문에 200 개까지 읽기가 쉽지 않은 20 개의 멤버 함수가있는 클래스를 선호합니다. 우리는 그것을 바꿀 수 있습니다.

그러나 이것은 모두 "단순성"에 대한 우리의 개인적 정의에 달려 있습니다. "가독성은"일반적으로 변화하지 않는 그 누군가가 우리 단순한 인간의 나머지 부분을 잊고, 예를 들어, 매우 "읽기"가 될 정규식 고려하는 것이 너무 많은 전문 지식과 실력을 인수하지 않는 한, 우리 사이에 격렬하게.

간단

오래 전에 "단순함"이 "가능한 한 읽기 쉬운"을 의미한다고 생각했던 시간이있었습니다. 그래서 많은 편의 기능으로 C 코드를 작성하여 구문을 개선하고 가능한 한 쉽게 읽고 쓸 수 있도록 노력했습니다.

결과적으로 매우 크고 풍부하며 높은 수준의 라이브러리를 설계하여 모든 자연스런 인간 사고에 대한 함수를 모델링하려고 시도했습니다. 도우미는 도우미를 돕는 도우미는 모두 클라이언트 코드를보다 읽기 쉬운 구문으로 만듭니다. 내가 작성한 코드는 가장 "읽기 쉬운"코드 일 수도 있지만 가장 "관리 불가능한"코드 나 "복잡한"코드이기도합니다.

리스프

그러나 나는 90 년대 중반 (후발 자)에 LISP와 짧은 열정을 가지고있었습니다. 그것은 "단순성"에 대한 나의 모든 생각을 바꾸었다.

LISP는 가장 읽기 쉬운 언어 가 아닙니다 . 중첩 된 괄호의 보트로드로 재귀 함수를 호출하는 동안 CDR과 CAR을 추출하는 것이 매우 "판독 가능"하다고 아무도 생각하지 않습니다.

그럼에도 불구하고, 내 두뇌가 언어의 이상한 구문과 일을하는 완전히 재귀적인 방식으로 둘러 싸이려고 애 쓰고 난 후에, 그것은 단순성에 대한 나의 생각을 영구적으로 바꾸었다.

내가 LISP에서 작성한 코드로 찾은 것은 더 이상 미묘한 오류를 일으키지 않았다는 것입니다. 미묘하고 예상치 못한 부작용으로 기능이 수행하고 누락 된 것을 오해하지 않았습니다. 나는 일반적으로 변경하고 올바른 프로그램을 작성하는 데 더 쉬운 시간을 보냈습니다.

LISP 후, 단순함은 미니멀리즘, 대칭, 유연성, 부작용 감소, 무한하지만 다양한 방식으로 결합되는 더 유연한 기능에 관한 것이되었습니다.

가장 안정적인 코드는 존재하지 않는 코드라는 사고 방식에 감사하게되었습니다. 그것은 조잡한 척도이지만, 수량에 기초한 코드의 신뢰성에 대한 가능성을 보는 경향이 있습니다. 최대한의 구문 적 편의성과 가독성을 찾는 것은 그 양을 크게 증가시키는 경향이 있습니다.

미니멀리즘

LISP 마인드가 내장되어있어 미니멀리즘 API를 선호하게되었습니다. 나는 "편리한"헬퍼의 보트로드를 제공하고 코드를 "읽기"쉽지만 잠재적으로 넘어갈 수있는 것보다 덜 편리하고 잠재력이 더 적은 읽기 쉽지만 신뢰성이 높고 유연한 기능을 갖춘 라이브러리를 선호합니다. 이러한 수천 가지 기능 중 하나의 기능에 대한 오해로 인한 불안정성과 놀라움에 대한 더 많은 문제.

안전

LISP의 또 다른 점은 안전이었습니다. 그것은 최소한의 부작용과 순수한 기능을 장려했으며, 언어로 읽고 쓰는 어려움이 10 초 후에 발견 할 수있는 명백한 실수를 증가 시켰지만 더 이상 미묘한 실수를하는 것을 보지 못했습니다.

순수한 함수와 불변의 상태는 다음과 같은 구문에도 불구하고 내가 감당할 수있을 때마다 나에게 더 좋아졌습니다.

sword = sharpen(sword)

...보다 생각이 덜 간단하고 인간의 생각과 분리되어 있습니다.

sharpen(sword)

가독성 vs. 간단

다시, LISP는 가장 "읽기 쉬운"언어가 아닙니다. 많은 논리를 작은 코드 섹션 (한 줄에 여러 사람이 생각할 수 있음)으로 묶을 수 있습니다. "가독성"에 대해 한 줄에 한 사람의 생각을 이상적으로 선호하는 경향이 있지만 반드시 "단순성"에 대한 것은 아닙니다.

이러한 "간단한"정의에서는 때때로 "단순한"이 실제로 "읽기 쉬운"과 다소 경쟁 할 수 있습니다. 이것은 인터페이스 디자인 관점에서 더 많은 것을 고려하고 있습니다.

간단한 인터페이스는 사용하기에 훨씬 적은 것을 배워야하며, 미니멀리즘의 결과로 잠재적으로 더 큰 신뢰성과 문제를 안게됩니다. 주제에 대한 포괄적 인 문서는 방대한 양의 책이 아니라 소책자에 적합 할 수 있습니다. 그럼에도 불구하고 좀 더 성가신 작업이 필요하고 읽을 수없는 코드가 생성 될 수 있습니다.

"간단하게"는 시스템의 기능을 폭넓게 이해하는 능력을 향상시킵니다. "읽을 수있는"기능은 각 작은 코드 줄을 자연 언어와 생각에 연결하는 능력을 향상 시키며, 특히 언어에 능숙하지 않은 경우 한 줄의 코드가 무엇을하는지 이해하는 속도를 높일 수 있습니다.

정규식은 내가 "매우 간단한"것으로 간주하는 예입니다. 개인적인 취향으로는 "너무 단순하고 읽을 수 없습니다". 이러한 극단 사이에는 균형 잡힌 행동이 있지만 정규 표현식은 정의 할 때 LISP와 같은 단순성 품질을 가지고 있습니다 : 미니멀리즘, 대칭, 놀라운 유연성, 신뢰성 등. 정규식의 문제는 너무 간단하여 내가 유창하게 될 것이라고 생각하지 않는 시점까지 너무 읽을 수 없게되었습니다 (내 두뇌는 그렇게 작동하지 않으며 정규식 코드를 유창하게 작성할 수있는 사람들을 부러워합니다).

어쨌든, 그것은 "단순성"에 대한 나의 정의이며, 그것은 "가독성"과 완전히 독립적이며 때로는 다른 것을 방해 할 수있어보다 "구문 적으로 편리"하고 읽을 수 있지만 더 큰 라이브러리 또는 불편하고 읽기 쉽지는 않지만 더 작은 라이브러리입니다. 나는 가독성에 대한 약간의 비용과 더 자연스러운 인간 구문 (그러나 정규 표현식의 시점이 아닌)에서도 미니멀리즘에 대한 강한 선호를 가지고, 진정한 "이해의 편의성"과 진정한 "유지 보수성"우선 순위를 발견했다. . YMMV.

항상? - 예

올바른 수준의 단순성을 달성하는 것은 복잡하고 어려운 일입니다. 그러나 항상 가독성을 향상시키기 때문에 항상 가치가 있습니다. 핵심은 깊은 이해라고 생각합니다. 단순성은 코드의 "청크 (chunk)"당 "새로운 개념"으로 측정 된 절대적인 것입니다. 몇 가지 새로운 개념은 더 간단합니다.

개념이 밀집된 영역에 집중하고 "청크"또는 "요약"또는 "추상"하는 방법을 찾으십시오. 더 간단하고 읽기 쉬운 코드를 통해 몇 번의 패스를 만드십시오.

좋은 추상화는 금의 무게 가치가 있습니다. 좋은 추상화는 이것을 더 단순하게하고 결과적으로 더 읽기 쉽다.

질문은 Stack Overflow에 대한이 답변 , 특히이 인용문 (간단하게 품질 대체)을 상기시킵니다 .

품질-당신은 그것이 무엇인지 알지만, 그것이 무엇인지 모릅니다. 그러나 그것은 모순입니다. 그러나 어떤 것이 다른 것보다 낫습니다. 즉, 품질이 더 좋습니다. 그러나 품질이있는 것을 제외하고 품질이 무엇인지 말하려고하면 모두 질식합니다! 할 말이 없습니다. 그러나 품질이 무엇인지 말할 수 없다면 품질이 무엇인지 또는 품질이 존재한다는 것을 어떻게 알 수 있습니까? 아무도 그것이 무엇인지 모른다면, 모든 실제적인 목적으로 전혀 존재하지 않습니다. 그러나 모든 실질적인 목적을 위해 실제로 존재합니다. 그 밖의 성적은 무엇입니까? 사람들은 왜 다른 것들에 대해 돈을 지불하고 다른 것을 쓰레기 더미에 버릴까요? 분명히 어떤 것이 다른 것보다 낫습니다. 그러나``더 나은 ''은 무엇입니까? -빙글 빙글 돌면서 정신 바퀴를 돌리고 견인을 얻을 수있는 곳을 찾지 못했습니다. 도대체 품질이란 무엇입니까? 무엇입니까?

모든 이점에 대해 체계화 된 코딩 표준이 좋은 프로그래머를 나쁜 프로그래머로 만들 수는 없다는 점을 명심해야합니다. '간단한'과 같은 단어는 다른 사람들에 의해 다르게 해석 될 수 있지만 (Aidan Cully의 답변 참조) 그렇게 나쁜 것은 아닙니다. 주니어 프로그래머는 여전히 수석 프로그래머가 코드를 검토하고 '간단한'에 대한 수석 프로그래머의 해석이 자신의 것보다 나은 이유를 알아야합니다.

라인 당 하나의 함수 호출이 더 간단합니까? 예를 들어 봅시다!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

어떻게 생각해? 회선 당 한 번의 통화가 실제로 더 간단합니까?