어떤 시점에서 루프 내에 루프를 갖는 것이 금기입니까?

그냥 궁금해서 Linus Torvalds 에서 이것을 읽은 후 for 루프 내에서 for 루프가 가장 많이 사용되었습니다 .

탭은 8 자이므로 들여 쓰기도 8 자입니다. 들여 쓰기를 4 자 (또는 2 자)까지 만들려고하는 이단 운동이 있으며, PI의 값을 3으로 정의하려고하는 것과 비슷합니다.

이론적 근거 : 들여 쓰기의 기본 개념은 제어 블록이 시작하고 끝나는 위치를 명확하게 정의하는 것입니다. 특히 20 시간 동안 화면을보고있을 때 들여 쓰기가 큰 경우 들여 쓰기가 어떻게 작동하는지 훨씬 쉽게 알 수 있습니다.

이제 어떤 사람들은 8 자 들여 쓰기를하면 코드가 오른쪽으로 너무 멀리 이동하여 80 자 터미널 화면에서 읽기가 어렵다고 주장 할 것입니다. 이에 대한 답은 3 단계 이상의 들여 쓰기가 필요한 경우 어쨌든 망쳐 져 프로그램을 수정해야한다는 것입니다.

https://www.kernel.org/doc/Documentation/CodingStyle

루프의 세 번째 레이어로 이동하는 것이 용납 할 수없는 관행이라고 생각하고 내 코드 (기본적으로 Qt)를 재구성 할 것입니다.

Linus가 농담 했습니까?

언어 나 응용 프로그램에 따라 달라 집니까?

3 단계 이상의 루핑 레벨이 절대적으로 필요한 것이 있습니까?

커널은 간단한 알고리즘을 강력하게 선호합니다

다양한 알고리즘에는 루프 내에 깊게 중첩 된 루프가 필요할 수 있지만 Linux 커널과 관련하여 (견적이 언급 된) 일반적으로 빠른 실시간 응답이 필요합니다. 이러한 맥락에서 딥 네 스팅은 코드 흐름이이 도메인에 비해 너무 복잡하고 가독성이나 들여 쓰기 문제가 아니라 실행 특성으로 인해 변경되어야 할 수도 있음을 나타내는 냄새입니다.

또한 Linux 커널은 감사 및 테스트 요구 사항과 관련하여 대부분의 응용 프로그램 코드와 다르므로 단일 함수에 4+ 수준의 중첩 알고리즘 을 사용 하지 않는 것이 좋습니다. 가능한 모든 제어 흐름 및 엣지 사례를 포함하여 각 코드 조각이 정확 하고 상세하게 수행하는 작업을 확인해야합니다 . 깊게 중첩 된 코드는 방해가됩니다.

어느 정도까지, 나는 "Tabs are 8 characters" 에서이 인용을 진지하게 받아들이지 않았다 . Tabulators의 요점은 고정 된 수의 문자가 아니라는 것입니다 (만약 탭이 하나의 문자입니다). 얼마나 많은 똥. 마찬가지로, 나는 완전히 (대한 하드 및 빠른 규칙을 설정하는만큼 "들여 쓰기의 세 가지 수준"의 하드 및 빠른 규칙을 설정하는 것은 제정신이라고 확신 아니에요 아무것도 제정신입니다).

그러나 들여 쓰기 수준을 제한하는 것은 일반적으로 합리적인 제안이며, 당신에게 놀라운 일이 아닙니다.

궁극적으로 프로그램에 세 가지 수준의 반복이 필요한 경우 프로그램에 필요한 것 입니다. 인용의 정신은 프로젝트의 요구 사항을 마술처럼 완화시키는 것이 아니라 코드가 더 선명하고 표현력이 있도록 논리를 함수와 유형으로 끌어 올리는 것입니다.

이것은 들여 쓰기 수준과 관련하여 위에서 주어진 동일한 지침으로 다시 피드백됩니다. 코드를 구성하고 앞으로 몇 년 동안 코드를 읽고, 유지 관리 가능하며, 재미있게 수정하는 방법에 관한 것입니다.

요점은 모든 흐름 제어 구문과 동일합니다. 코드를 이해하기 어려운 경우 리팩터링해야합니다. 다차원 배열을 약간 조작하는 경우 가장 안쪽 루프의 논리가 간단하다면 5-6 깊이의 루프를 중첩하는 것이 적절할 수 있습니다. 그러나 복잡한 비즈니스 로직을 처리하고 있고 루프 본문이 12 줄 이상인 경우 둘 이상의 루프를 중첩하지 않을 수 있습니다. 코드 의 순환 복잡성 을 계산해 볼 수는 있지만 문제의 코드는 가독성과 유지 관리 가능성입니다.

Linus가 농담 했습니까?

이 작품은 장난스러운 스타일로 작성되어 저자가 코딩 스타일이 심각한 실무자들 사이에서 논의되는 방식에 익숙하다는 것을 암시합니다. 우리는 그것이 개인적인 취향의 문제라는 것을 완벽하게 이해합니다. 그는 많은 말로, "Coding style is very personal, and I won't _force_ my views on anybody"적어도 개인적으로 유지하는 코드 외부에 있다고 말합니다 . 그러나 주어진 프로젝트에서 스타일의 일관성은 매우 좋습니다. 주어진 함수에서 여러 스타일을 처리하는 것보다 싫어하는 스타일로 코딩하는 것이 좋습니다.

다음은 분명히 재미있는 글쓰기의 예입니다.

However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:

int function(int x)
{
    body of function
}

Heretic people all over the world have claimed that this inconsistency
is ...  well ...  inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.  Besides, functions are
special anyway (you can't nest them in C).

장난이 심하다 (1).

3 단계 최대 값은 쌍곡선 일 수 있지만, 들여 쓰기를 제어 할 수 없도록 유지하는 것이 좋습니다. 나는 커널 소스를 grep하지 않고 네 개의 탭 문자 시퀀스를 세지 않을 것이지만 Torvalds가 쓴 적어도 하나를 찾을 수있을 것이라고 확신합니다.

반면에 누군가가 종종 3 단계의 들여 쓰기를 초과하지 않고 Linux 커널을 작성할 수 있다면 3 단계 한계는 자신의 코드에서 잠시 동안 시도해 볼 가치가있는 운동 일 수 있습니다. 이것은 섹스 변화와는 다릅니다. 평생의 약속이 아닙니다.

인터넷에서 Torvalds (2)보다 프로그래밍을 훨씬 잘 이해한다고 생각하는 사람을 만나면 어떤 종류의 사람들이 인터넷에서 큰 대화를 좋아하는지 알 수 있습니다.

다른 한편으로, 그는 여덟 개의 공백 탭에 대해 범죄 적으로 잘못되었습니다. 그것은 감금 상태로 유지되고 슬롯을 통해 공급되어야하는 사람의 열망입니다. 네 개의 공백이 분명히 맞습니다.

(1) 그러나 어떻게 그가 타원 앞에 공백을 두 개, 그 뒤에 공백 두 개를, 그리고 완전히 멈춘 후 두 공백을 잘못 두는지를 주목하십시오. 잘못된, 잘못된, 잘못된. 그리고 나서 그는 이단자들을 징계 할 용감한 담즙을 가지고 있습니다. 이단은 너야, 토발즈! 그건 너다!

(2) " 소스 제어 시스템을 설계하는 방법 이해 "에 대해 이야기하고 싶다면 토론의 여지가있을 수 있습니다.

참고 : 동일한 편집을 반복적으로 제출 한 친애하는 사용자 : 인용 된 자료의 형식은 작성자가 의도 한대로 정확하게 유지됩니다. 고정 너비 텍스트의 형식을 공정하게 생각한 사람이 고정 너비 텍스트로 작성된 고정 너비 텍스트의 형식에 대한 에세이에서 나온 것이기 때문입니다. 형식은 저자의 의도의 의식적이고 의도적 인 부분이며 주제와 관련이 있습니다.

또한 나는 내 자신의 텍스트에서 그 형식을 다시 언급했다. 사전 서식을 설정하면 각주 (1)가 횡설수설됩니다. 사전 서식이 제거되면 문장 끝에서 완전히 멈춘 후 공백 쌍을 참조하는 각주 (1)의 텍스트가 있어야합니다. 어쨌든 그 주석을 작성했을 때보 다 덜 재미있어서 각주를 제거하는 근거를 알 수 있습니다. 그러나 각주를 제거하지 않고 서식을 제거하는 것은 도움이되지 않습니다.

Linus는 매우 무뚝뚝한 말하기 스타일과 건조한 유머 감각을 지녔지 만이 경우 농담하지 않았습니다. 알고리즘 이 두 수준보다 깊게 중첩되어야 하는 상황이 있지만 코드 들여 쓰기 이외의 다른 방법을 사용하여이를 수행 할 수 있습니다. 리눅스 커널 스타일 가이드는 깊게 중첩 된 루프를 유지하기가 어렵 기 때문에 이러한 다른 방법을 선호합니다. 이것이 Linus가 말하는 것입니다.

대체 방법의 일부 예에서는 재귀를 사용하거나 내부 루프를 자체 함수로 분리하거나 중간 데이터 구조를 만들 수 있습니다.

과도한 중첩은 작성하기는 쉽지만 읽기가 어려운 경우 중 하나입니다. 큰 탭 깊이를 설정하는 것은 Linus가 쓰기를 더 성가 시게하는 방법입니다.

질문을하는 사람과 질문하지 않은 사람에 대한 조언이 다른 많은 질문이 있습니다. "두 레벨 이상으로 중첩 된 루프가 있어야합니까?"라고 묻는다면 그 질문을하는 사람은 아니오입니다. 요청하면하지 마십시오. 당신이 물어볼 필요가없는 충분한 경험이 있다면, 당신은 각 경우에 정답이 무엇인지 안다. 대답이 당신을위한 것이 아니기 때문에 대답에 동의하지 않는다면 논쟁하지 마십시오.

이것은 개를 흔드는 꼬리의 교과서 사례 인 것처럼 보입니다.

80 문자 디스플레이를 가지고 있다면 물론 코드에 가장 적합한 구조를 만들지 않아도 코드를 가장 잘 맞출 수 있습니다 .

나머지 포인트를 해결하려면 다음을 수행하십시오.

나는 그것이 받아 들일 수없는 관행이라고 생각했다.

나는 당신이 이것에 대해 너무 많이 읽고 있다고 생각합니다. 문맥을 제대로 이해하지 않고 복음으로 읽은 모든 것을 가져 가려는 충동에 저항하십시오.

농담 했어?

상황을 확인하기는 어렵지만 위의 원래 요점을 참조하십시오.

언어 나 응용 프로그램에 따라 달라 집니까?

매우 그렇다. 터미널 (또는 터미널 에뮬레이터)에서 코딩 할 가능성이있는 메인 프레임 / 중급 언어를 사용하십시오.

3 단계 이상의 루핑 레벨이 절대적으로 필요한 것이 있습니까?

예, 일부 무차별 알고리즘에서는 매우 일반적입니다. 프로젝트 오일러의 문제 31 을 참조하십시오 . 이것은 많은 루프 (정확히 8)를 사용하여 무차별하게 해결 될 수있는 문제의 전형적인 예입니다.

Linus가 농담 했습니까?

아니요, 공식 지침입니다.

언어 나 응용 프로그램에 따라 달라 집니까?

코딩 지침은 일반적으로 언어와 응용 프로그램에 따라 다르지만 깊게 중첩 된 코드는 항상 독자에게 부담을줍니다.

중첩 코드의 문제점은 일반적으로 순환 복잡성을 증가 시킨다는 것입니다. 즉, 코드가 중첩 될수록 잠재적 인 실행 경로가 함수 내에 존재한다는 것입니다. 잠재적 인 실행 경로의 조합 폭발은 코드에 대한 추론을 어렵게하므로 일반적으로 피해야합니다.

왜 3입니까? 주관적인 코딩 지침은 시행하기 어렵고 자동으로 시행하기가 불가능합니다. 최대 들여 쓰기 수준에서 객관적인 코딩 지침을 설정하려면 Linux 커널에서 3을 선택해야합니다.

그것은 임의적이며 분명히 충분합니다.

3 단계 이상의 루핑 레벨이 절대적으로 필요한 것이 있습니까?

그러나 알고리즘 측면에서는 아마도 표현력이 충분한 언어에서는 코드를 더 작은 청크로 리팩토링 할 수 있습니다 (함수 또는 클로저와 상관없이).

계약을 철자하지 않고도 서로를 호출하는 작은 중첩과 많은 작은 함수로 난독 화 된 코드를 작성할 수 있습니다 ...

... 그러나 계약이 명확한 작은 기능은 계약이 명확한 큰 기능보다 감사하기가 훨씬 쉽습니다.