들여쓰기 스타일

Indentation style

컴퓨터 프로그래밍에서 들여쓰기 스타일은 프로그램 구조를 전달하기 위한 코드 블록 들여쓰기를 관리하는 규칙이다.이 문서에서는 주로 C 및 그 하위 언어 등의 자유 형식 언어에 대해 다루지만 공백이 중요하지 않은 대부분의 다른 프로그래밍 언어(특히 괄호 패밀리에 있는 언어)에 적용할 수 있습니다.들여쓰기 스타일은 프로그래밍 스타일의 한 측면일 뿐입니다.

대부분의 프로그래밍 언어에서는 들여쓰기가 2차 표기법으로 사용되는 것이 아닙니다.오히려, 들여쓰기는 프로그램의 구조를 인간 독자들에게 더 잘 전달하는 데 도움이 된다.특히 조건이나 루프 등의 제어 플로우 구조와 그 내부 및 외부에 포함되는 코드 간의 링크를 명확히 하기 위해 사용된다.그러나 일부 언어(Python이나 occam )에서는 괄호나 키워드를 사용하는 대신 들여쓰기를 사용하여 구조를 결정합니다.이것을 오프사이드 규칙이라고 부릅니다.이러한 언어에서 들여쓰기는 컴파일러나 인터프리터에게 의미가 있습니다.이것은 명확성이나 스타일의 문제일 뿐만이 아닙니다.

이 문서에서는 괄호라는 용어괄호를 나타내며 괄호라는 용어는 곱슬 괄호를 나타냅니다.

복합문에서의 괄호 배치

들여쓰기 스타일의 주요 차이점은 복합문의 괄호 배치에 있습니다.{...}control 스테이트먼트 뒤에 나오는 경우가 많다( ).if,while,for...) 다음 표는 이 문서에서 설명하는 스타일의 문구를 나타낸 것입니다.함수 선언 스타일은 다른 경우입니다.문의 가새 배치 스타일은 함수 정의의 가새 배치 스타일과 다를 수 있습니다.일관성을 위해 각 스타일의 원하는 들여쓰기 깊이에 관계없이 들여쓰기 깊이는 4개의 공간으로 일정하게 유지됩니다.

브레이스 배치 스타일
하는 동안에 (x == y) {     뭔가();     무엇인가(); } 
올맨
하는 동안에 (x == y) {     뭔가();     무엇인가(); } 
K&R
하는 동안에 (x == y)   {     뭔가 ();     무엇인가 ();   } 
GNU
하는 동안에 (x == y)     {     뭔가();     무엇인가();     } 
화이트스미스
하는 동안에 (x == y) {   뭔가();     무엇인가(); } 
호르스트만
하는 동안에 (x == y)   { 뭔가()   ; 무엇인가()   ;   } 
하스켈
하는 동안에 (x == y) {   뭔가();     무엇인가(); } 
피코
하는 동안에 (x == y) {     뭔가();     무엇인가();     } 
래틀리프
하는 동안에 (x == y)   { 뭔가();     무엇인가(); } 
리스프
#정의 W(c,b) {while(c){b}} W(x==y,s();인식하다();) 
APL

탭, 공백 및 들여쓰기 크기

표시되는 탭의 너비는 Notepad+(MS-Windows), TextEdit(MacOS/X), Emacs(Unix), vi(Unix), nano(Unix) 등 대부분의 프로그래밍 편집기에서 임의 값으로 설정할 수 있습니다.또한 이러한 편집기는 탭과 공간을 혼합하여 생성하거나 탭과 공간을 변환하여 특정 들여쓰기 방식과 일치하도록 구성할 수 있습니다.Unix 에서는, 탭폭도, 예를 들면 「less」호출기로 설정할 수 있습니다.또, expand/unexpand등필터에 의해서, 즉석에서 변환할 수도 있습니다.

Unix 에디터는 기본적으로 8열 간격으로 탭을 배치하는 반면 Macintosh 및 MS-Windows 환경은 기본적으로 4열로 설정됩니다.탭과 공백이 혼합된 들여쓰기가 작성자 구성과 다르게 탭을 표시하는 구성에서 표시될 경우, 이 차이로 인해 소스 코드가 정렬되지 않습니다.

프로그래머들 사이에서 하드 탭과 스페이스 중 어느 쪽을 선택할지에 대한 논쟁이 계속되고 있습니다.많은 초기 프로그래머들은 탭 문자를 들여쓰기, 입력의 용이성 및 소스 파일 크기 저장을 위해 사용했습니다.Jamie Zawinski와 같은 일부 프로그래머는 탭 대신 공간을 사용하면 크로스 플랫폼 이동성[1]향상된다고 말합니다.WordPress 코딩 표준의 작성자와 같은 다른 기술자들은 하드 탭이 휴대성을 [2]증가시킨다고 말합니다.GitHub의 상위 40만 개의 저장소를 조사한 결과, 공간이 더 [3]일반적이었습니다.

일반적으로 들여쓰기 크기는 스타일과 무관합니다.1983년 PASCAL 코드에 대해 수행된 실험에서 움푹 패인 크기가 이해성에 큰 영향을 미친다는 것을 발견했습니다.2 ~ 4글자 사이의 들여쓰기 크기가 [4]최적의 것으로 판명되었습니다.Ruby, 많은 셸 스크립트 언어 및 일부 HTML 포맷경우 일반적으로 들여쓰기 수준당 2개의 공간이 사용됩니다.[citation needed]

도구들

들여쓰기 스타일 간에 다음과 같은 여러 가지 도구를 변환할 수 있습니다.indent 많은 Unix 계열 운영체제에 포함되어 있는 프로그램입니다.

Emacs에서는 입력 문제를 자동으로 수정하기 위해 다양한 명령어를 사용할 수 있습니다.Tab(디폴트 설정으로) 소정의 회선상에 있습니다. M-x indent-region를 사용하여 코드의 큰 부분을 올바르게 들여쓸 수 있습니다.모드에 따라서는, Emacs 는 선두의 들여쓰기 스페이스를 적절한 수의 탭으로 치환할 수도 있습니다.그 결과, 각 소스 행을 들여쓰기 위한 문자수가 최소한으로 억제됩니다.

탄력적인 탭스톱은 텍스트 편집기의 지원이 필요한 표 형식이며, 블록의 한 줄 길이가 변경되면 전체 텍스트 블록이 자동으로 정렬됩니다.

스타일

K&R 스타일

K&R 스타일(Kernighan & Ritchie Style) 및 해커 전문[5][6] 용어(1TBS로[7] 줄임말)의 밀접하게 관련된 "1개의 진정한 브레이스 스타일"은 C, C+기타 컬리 브레이스 프로그래밍 언어에서 일반적으로 사용됩니다.이것은 오리지널 Unix 커널인 KernighanRitchie의 The C Programming Language와 Kernighan과 Plauger의 책 The Elements of Programming Style에 사용된 스타일입니다.

K&R을 따를 때 각 함수는 헤더와 같은 들여쓰기 레벨의 다음 줄에 오프닝 브레이스를 가지고 있으며, 괄호 내의 문장은 들여쓰기되며, 끝부분의 닫힘 브레이스는 자신의 줄에 있는 함수의 헤더와 같은 들여쓰기 레벨에 있다.

단, 함수 내의 여러 줄 블록은 각각의 제어문과 같은 줄에 오프닝브레이크가 있습니다.닫는 중괄호는 키워드가 뒤따르지 않는 한 독자적인 행에 남습니다.else또는while이렇게 정렬되지 않은 교정기는 고대 이집트인들의 [8][9][10]상상적인 포즈에서 팔을 닮았다고 해서 "이집트 교정기" (또는 "이집트 괄호")라는 별명을 가지고 있습니다.K&R에서는 한 줄 블록에는 중괄호가 없습니다.

인트 주된(인트 argc,  *argv[]) {     ...     하는 동안에 (x == y) {         뭔가();         무엇인가();          한다면 (일부 오류)             do_수정(); // K&R에서는 단일 스테이트먼트블록에 중괄호가 없습니다.         또 다른             continue_as_continue();     }      최종적인 것();     ... } 

C 프로그래밍 언어에서는 이 스타일이 명시적으로 지정되어 있지 않지만, 이 스타일은 책 전체에서 일관되게 되어 있습니다.책에서 본 내용:

치열 교정기의 위치는 비록 사람들이 열정적인 신념을 가지고 있지만 덜 중요하다.몇 가지 인기 있는 스타일 중 하나를 선택했습니다.자신에게 맞는 스타일을 선택한 후 꾸준히 사용하세요.

이전 버전의 C 언어에서는 인수 유형을 후속 행에서 선언할 필요가 있었습니다(즉, 함수 헤더 직후).

/* 기능 시제품이 없는 ISO C 이전의 오리지널 스타일 */ 인트 주된(argc, argv)     인트   argc;       *argv[]; {     ... } 

종류: 1 TBS (OTBS)

"1개의 진정한 브레이스[7] 스타일"(1TBS 또는 OTBS로 줄임말)은 K&R과 매우 유사합니다.두 가지 주요 차이점은 함수의 오프닝브레이크가 같은 줄에 공백으로 구분되어 있다는 점과 범위에 [11]문이1개밖에 없는 컨트롤 스테이트먼트에서는 중괄호가 생략되지 않는다는 점입니다.

이 스타일에서는 새 코드 라인을 삽입할 수 있는 구성 요소는 별도의 줄에 있고 삽입을 금지하는 구성 요소는 한 줄에 있습니다.이 원리는 한 줄 조건 등을 포함한 모든 if, 그 외 모든 경우에 가새김으로써 증폭되어 새로운 코드 행을 항상 안전하게 삽입할 수 있습니다(즉, 이러한 삽입으로 인해 실행 흐름이 소스 코드 식별과 불일치하지 않습니다.

이 스타일의 권장되는 장점은 시작 괄호에만 추가 행이 필요하지 않고 끝 괄호는 개념적으로 속한 문장과 일치한다는 것입니다.이 스타일의 비용 중 하나는 블록의 끝 부분에만 완전한 줄이 필요하며, 이는 if/else 블록과 do/while 블록으로 부분적으로 해결할 수 있습니다.

무효 체크 네거티브(x) {     한다면 (x < > 0) {         놓다("부정적");     } 또 다른 {         부정적이지 않다(x);     } } 

The One True Brace Style에 대한 많은 언급이 있지만, 그것의 진짜 형태에 대해서는 약간의 혼란이 있다.어떤 소식통들은 이것이 [11]위에 명시된 변형이라고 말하는 반면, 다른 소식통들은 단지 K&[5]R의 또 다른 "해커 전문 용어"라고 지적한다.

종류: Linux 커널

K&R 스타일의 작은 변형은 Linux [12]커널 스타일로 Linux 커널의 소스 트리에서 광범위하게 사용되는 것으로 알려져 있습니다.Linus Torvalds는 모든 기여자들에게 그것을 따르라고 강력히 권고한다.이 스타일은 K&R에서 많은 요소를 차용하고 있습니다.

커널 스타일은 들여쓰기에 탭 중지(8자마다 탭 중지 설정)를 사용합니다.함수의 열림 중괄호는 함수 헤더 다음에 이어지는 줄의 선두로 이동합니다.다른 모든 여는 물결 괄호는 대응하는 문과 같은 줄에 공백으로 구분되어 있습니다.의 라벨switch문이 둘러싸인 블록과 정렬됩니다(인디트 레벨은 1개뿐입니다).이전에는 행 길이가 80자로 제한되었지만 2020년에는 100자로 증가했지만 여전히 원래 제한이 [13]선호됩니다.복합문의 단일 스테이트먼트 본문(if, while, do-while 등)은 중괄호로 둘러싸여 있을 필요가 없습니다.단, 1개 이상의 서브스테이트먼트가 있는 경우if-else스테이트먼트에는 중괄호가 필요합니다.그러면 두 개의 서브스테이트먼트는 모두 곱슬곱슬한 중괄호로 둘러싸야 합니다.

인트 (인트 x, 인트 y) {         인트 결과;          한다면 (y < > 0) {                 결과 = 0;         } 또 다른 {                 결과 = 1;                 하는 동안에 (y-- > 0)                         결과 *= x;         }         돌아가다 결과; } 

변형: 필수 브레이스

일부에서는 한 줄의 코드를 항상 안전하게 삽입할 수 있도록(즉, 이러한 삽입이 소스 코드 들여쓰기와 실행 흐름을 반대하지 않음) 단일 줄 조건 등을 포함한 모든 if, other, while 등을 브레이싱하는 제어문에 대한 필수 중괄호를 지지한다.

이 스타일의 비용은 마지막 블록에 1개의 추가 풀 라인이 필요하다는 것입니다(if/else if/else if/else 및 do/while 블록의 중간 블록 제외).

종류: Java

Java가 다른 스타일로 작성되는 경우도 있지만, Java 코드의 상당 부분은 K&R 스타일의 마이너 변형을 사용합니다.K&R 스타일에서는 함수 내부의 블록뿐만 아니라 클래스나 메서드 선언에도 같은 줄에 여는 괄호가 있습니다.이 스타일은 주로 Sun Microsystems의 오리지널 스타일[14][15][16] 가이드가 이 K&R 변종을 사용했기 때문에 널리 퍼져 있으며, 그 결과 Java API의 표준 소스 코드는 대부분 이 스타일로 작성되어 있습니다.또한 Allman 스타일과 함께 ActionScript 및 JavaScript에서 자주 사용되는 들여쓰기 스타일입니다.

종류:스트루스트럽

Strustrup 스타일은 Bjarne Strustrup이 C++를 사용한 프로그래밍: C++[17]사용한 원칙과 실천과 같은 그의 저서에 사용된 K&R 스타일을 C++에 맞게 개작한 것입니다.

위의 변형과 달리 Strustrup은 "cuffed other"를 사용하지 않습니다.따라서[17] 스트루스트럽은

    한다면 (x < > 0) {         놓다("부정적");         아니요.(x);     }     또 다른 {         놓다("음수 없음");         부정적이지 않다(x);     } 

Strustrup은 다음과 같이 K&R 스타일을 확장합니다.

    학급 벡터 {     일반의:         벡터(인트 s) :일람(신규 이중으로 하다[s]), 스즈(s) { }   // 벡터 생성         이중으로 하다& 교환입니다.[](인트 i) { 돌아가다 일람[i]; }   // 요소 액세스: 서브스크립션         인트 크기() { 돌아가다 스즈; }     사적인:         이중으로 하다 * 일람;    // 요소에 대한 포인터         인트 스즈;           // 요소 수     }; 

Strustrup이 라벨을 들여쓰지 않음public:그리고.private:또한 이 스타일에서는 함수의 오프닝 브레이스가 새로운 행에서 시작되지만 클래스의 오프닝 브레이스는 클래스 이름과 같은 행에 있습니다.

Strustrup을 사용하면 짧은 함수를 한 줄에 모두 쓸 수 있습니다.Strustrup 스타일은 Editor Emacs에서 사용할 수 있는 이름 있는 들여쓰기 스타일입니다.Strustrup은 최신 C++ 핵심 [18]가이드라인에서 언급한 바와 같이 C++와 함께 K&R에서 파생된 스타일 레이아웃을 권장합니다.

종류: BSD KNF

커널 노멀 폼이라고도 불리는 이것은 버클리 소프트웨어 배포(BSD) 운영 체제에서 사용되는 대부분의 코드 형식입니다.주로 커널 코드를 목적으로 하지만 사용자 랜드 코드에서도 널리 사용됩니다.기본적으로 Bell Labs 버전6 및 7 Unix 소스 [19]코드에서 사용되는 K&R 스타일의 변종입니다.

SunOS 커널 및 사용자랜드에서도 비슷한 들여쓰기 [19]스타일이 사용됩니다.KNF와 마찬가지로, 이 또한 AT&T 스타일의 문서에 근거하고 있으며, Bill Joy Normal [20]Form이라고 불리기도 합니다.SunOS 가이드라인은 1996년에 발행되었습니다.ANSI C에 대해서는 간단히 설명합니다.소스 파일 목록의 들여쓰기가 올바른지 여부는 Bill [19][20][21]Shannon이 작성한 cstyle 프로그램으로 확인할 수 있습니다.

이 스타일에서는 하드태블레이터(ts in vi)는 8컬럼으로 유지되며 소프트태블레이터는 도우미(sw in vi)로 정의되어 4컬럼으로 설정됩니다.하드 탭은 코드 블록의 들여쓰기에 사용되며, 추가 들여쓰기의 소프트 탭(4스페이스)은 여러 줄로 분할해야 하는 모든 연속 행에 사용됩니다.

게다가 함수 호출은 괄호 앞에 공간을 사용하지 않지만 다음과 같은 C 언어의 네이티브 스테이트먼트는if,while,do,switch그리고.return(만일의 경우) 하다returnparen과 함께 사용됩니다).최상위 블록에 로컬 변수를 선언하지 않는 함수도 첫 번째 블록 중괄호 뒤에 빈 행을 남겨야 합니다.

다음은 몇 가지 샘플입니다.

하는 동안에 (x == y) {         뭔가();         무엇인가(); } 최종적인 것(); 

한다면 (데이터. != 특수한 순서 & & 인식하다 > 0) {         한다면 (JS_DefineProperty(cx, o, "데이터",             STRING_TO_JSVAL(JS_NewStringCopyn(cx, 데이터., 인식하다)),             특수한 순서, 특수한 순서, JSPROP_Enumerate) != 0) {                 큐_예외("내부 오류!");                 에 가다 에러;         }         프리엠(데이터.); } 또 다른 {         한다면 (JS_DefineProperty(cx, o, "데이터", 오브젝트_TO_JSVAL(특수한 순서),             특수한 순서, 특수한 순서, JSPROP_Enumerate) != 0) {                 큐_예외("내부 오류!");                 에 가다 에러;         } } 

정적인 JS부루 pgresult_paramor(JS콘텍스트 *cx, JSObject *obj, 네트워크 argc,     jsval *argv, jsval *반응하다) {          큐_예외("PGRESULT 클래스는 사용자가 즉시 사용할 수 없습니다.");          돌아가다 (JS_FALSE); } 

올맨 스타일

올맨 스타일은 에릭 올먼의 이름을 따왔다.올먼이 BSD 유닉스용 유틸리티의 대부분을 작성했기 때문에 BSD 스타일이라고도 불린다.

이 스타일은 제어문과 같은 수준으로 들여쓰기된 다음 줄에 제어문과 관련된 가새(brack)를 배치합니다.괄호 안의 문은 다음 수준으로 [22]들여씁니다.

하는 동안에 (x == y) {     뭔가();     무엇인가(); }  최종적인 것(); 

이 스타일은 Pascal 언어Transact-SQL에서 사용되는 표준 들여쓰기와 유사하며, 여기서 중괄호는 키워드와 동일합니다.begin그리고.end.

(*Pascal의 Allman 코드 들여쓰기 스타일 예시 *) 절차. 어떻게 좀 해봐.(x, y: 정수); 시작한다.     하는 동안에 x = y 하다     시작한다.         뭔가();         무엇인가();     끝.; 끝.; 

이 스타일의 결과, 거의 모든 공백인 행과 닫힘 괄호가 시작 괄호와 같은 열에 있는 행에 의해 삽입된 코드가 포함 문과 명확하게 구분됩니다.어떤 사람들은 이것이 일치하는 교정기를 쉽게 찾을 수 있게 한다고 생각한다.또한 차단 스타일은 연관된 제어 문에서 코드 블록을 나타냅니다.제어문이나 코드 블록 또는 코드 리팩토링의 주석 또는 삭제는 모두 중괄호 또는 누락으로 인해 구문 오류가 발생할 가능성을 낮춥니다.또한 외측 기능 블록의 브레이스 배치와 일치한다.

예를 들어, 구문적으로는 다음과 같습니다.

// 동안 (x == y) {     뭔가();     무엇인가(); } 

이하와 같이:

// for (int i=0; i < x; i++) // 동안 (x == y) 한다면 (x == y) {     뭔가();     무엇인가(); } 

조건 컴파일을 사용하면 다음과 같이 됩니다.

    인트 c; #ifdef HAS_GETCH     하는 동안에 ((c = 취득하다()) != EOF) #실패하다     하는 동안에 ((c = 취득하다()) != EOF) #엔디프     {         무엇인가 하다(c);     } 

종류:올맨-8

교육 [citation needed]분야에서 널리 사용되는 변형인 Allman-8은 K&R의 Linux Kernel 변형 중 8칸 들여쓰기 탭과 80칸 제한을 사용합니다.이 스타일은 프로젝터의 가독성을 향상시키는 데 도움이 된다고 합니다.또한 들여쓰기 크기와 열 제한은 코드 블록의 과도한 중첩을 식별하기 위한 시각적 신호를 만드는 데 도움이 됩니다.이러한 장점이 결합되어 새로운 개발자와 학습자가 코드의 [citation needed]복잡성을 관리하기 위한 암묵적인 지침을 제공하는 데 도움이 됩니다.

화이트스미스 스타일

Whitesmiths 스타일은 Wishart 스타일이라고도 불리며, 최초 상용 C 컴파일러인 Whitesmiths 컴파일러의 문서에서 사용되었습니다.또한 DurantProgrammer's Guide to Windows, Carlson & Yao의 Programming Windows, PetzoldProgramming Windows, Norton & Yao의 Windows 3.0 Power Programming Technics 등 3권의 영향력 있는 Windows 프로그래밍 책에도 사용되었기 때문에 Windows 초기에도 인기가 있었습니다.

Whitesmith는 Allman과 함께 가장 일반적인 브레이싱 스타일로 Joneson [5]File에 따르면 동일한 인기를 얻고 있습니다.

이 스타일은 다음 줄에 제어문과 연관된 가새(괄호)를 들여씁니다.괄호 안의 문은 괄호와 같은 수준으로 들여씁니다.

하는 동안에 (x == y)     {     뭔가();     무엇인가();     }  최종적인 것(); 

이 스타일의 장점은 올맨 스타일의 것과 비슷하다.블록은 제어문과 명확하게 구분됩니다.가새와 블록의 정렬은 전체 블록이 개념적이고 프로그래밍적으로 하나의 복합문임을 강조합니다.괄호를 들여쓰면 control 문에 종속되어 있음을 강조합니다.끝 괄호는 더 이상 문장과 일렬로 정렬되지 않고 시작 괄호와 함께 정렬됩니다.

예:

한다면 (데이터. != 특수한 순서 & & 인식하다 > 0)     {     한다면 (!JS_DefineProperty(cx, o, "데이터", STRING_TO_JSVAL(JS_NewStringCopyn(cx, 데이터., 인식하다)), 특수한 순서, 특수한 순서, JSPROP_Enumerate))         {         큐_예외("내부 오류!");         에 가다 에러;         }     프리엠(데이터.);     } 또 다른 한다면 (!JS_DefineProperty(cx, o, "데이터", 오브젝트_TO_JSVAL(특수한 순서), 특수한 순서, 특수한 순서, JSPROP_Enumerate))     {     큐_예외("내부 오류!");     에 가다 에러;     } 

else if진술로 취급되다#elifpreprocessor 스테이트먼트

GNU 스타일

Allman 스타일과 Whitesmith 스타일과 마찬가지로 GNU 스타일은 두 개의 공백으로 들여쓰기된 선 위에 괄호를 그어 놓습니다.단,[23] 들여쓰기되지 않은 함수 정의를 여는 경우는 제외합니다.어느 경우든 포함된 코드는 괄호에서2개의 공백으로 들여씁니다.

Richard Stallman에 의해 널리 알려진 레이아웃은 [24]리스프 코드를 작성한 그의 배경에 의해 영향을 받을 수 있습니다.Lisp에서는 블록(예측)에 상당하는 것은 1등급 데이터 엔티티이며, 독자적인 들여쓰기 레벨을 지정하면, C에서는 블록이 구문일 뿐입니다.이 스타일은 1960년대와 1970년대의 [25][26][discuss]일부 ALGOL 및 XPL 프로그래밍 언어 교과서에서도 찾아볼 수 있습니다.들여쓰기와 직접 관련이 없지만, GNU 코딩 스타일은 함수에 대한 인수 목록 앞에 공백도 포함합니다.

정적인  * 콘센트 ( *s1,  *s2) {   하는 동안에 (x == y)     {       뭔가 ();       무엇인가 ();     }   최종적인 것 (); } 

[23]

이 스타일은 AllmanWhitesmith의 장점을 결합하여 블록에서 눈에 띄지 않는 브레이스의 가능한 Whitesmith 단점을 제거합니다.한 가지 단점은 끝 괄호가 개념적으로 속한 문장과 더 이상 일치하지 않는다는 것입니다.또 하나의 단점은 하나의 개념 레벨에 대해 2개의 시각적 수준의 들여쓰기를 사용함으로써 공간을 낭비할 수 있다는 것입니다.단일 레벨 들여쓰기를 사용하는 시스템에서는 보통 각 레벨이 최소 4개의 공간, 즉 GNU 스타일의 2x2 공간과 같기 때문입니다.

GNU 코딩 표준은 이 스타일을 권장하고 있으며, GNU 프로젝트 소프트웨어의 거의 모든 유지관리자가 이 [citation needed]스타일을 사용합니다.

GNU Emacs 텍스트 에디터와 GNU 시스템의 intd 명령어는 기본적으로 [27]이 스타일에 따라 코드를 다시 포맷합니다.GNU Emacs를 사용하지 않는 사용자나 마찬가지로 확장 가능한 사용자 지정 편집기는 이 스타일에 도움이 되지 않을 수 있습니다.그러나 KNF 스타일로 기본 설정되는 많은 에디터들은 탭 너비가 두 칸으로 설정되면 GNU 스타일에 잘 대응합니다. 마찬가지로 GNU Emacs는 탭 너비를 8칸으로 설정하기만 하면 KNF 스타일에 잘 적응합니다.두 경우 모두 자동 재포맷으로 원래 간격이 파괴되지만 자동 줄 들여쓰기가 제대로 작동합니다.

Steve McConnell그의 책 Code Complete에서 이 스타일을 사용하지 말 것을 충고합니다.는 코드 샘플을 "Coding Horror" 아이콘으로 표시하고 특히 위험한 코드를 상징하며 가독성을 [28]방해한다고 말합니다.Linux 커널 코딩 스타일의 문서도 이 스타일에 대해 강력히 권장하고 있습니다.독자들은 GNU 코딩 표준의 복사본을 "훌륭한 심볼릭 제스처"[29]로 쓸 것을 권장합니다.

호르스트만 스타일

Cay S. Horstmann의 1997년 Computing Concepts with C++ Essentials는 블록의 첫 문장을 오프닝 브레이스와 같은 줄에 배치함으로써 Allman을 채택했습니다. 스타일은 Jensen and Worth의 Pascal 사용자 매뉴얼보고서 [30]예에도 사용됩니다.

하는 동안에 (x == y) {   뭔가();     무엇인가();     //...     한다면 (x < > 0)     {   인쇄물("부정적");         아니요.(x);     }     또 다른     {   인쇄물("음수 없음");         부정적이지 않다(x);     } } 최종적인 것(); 

이 스타일은 가독성을 위해 가새의 수직 정렬을 유지하고 K&R 스타일의 라인을 저장하여 블록을 쉽게 식별함으로써 Allman의 장점을 결합합니다.그러나 2003년판에서는 [31]Allman 스타일을 사용하고 있습니다.

피코 스타일

이것은 피코의 디자이너들에 의해 피코 언어로 가장 일반적으로 사용되는 스타일입니다.Pico에는 반환문이 없으며 종료자 대신 세미콜론을 문 구분자로 사용합니다.다음과 같은 [32]구문을 얻을 수 있습니다.

stuff(n): { x: 3 * n; y: doStuff(x), y + x }

화면 부동산을 K&R 스타일로 저축하는 것과 장단점이 비슷하다.또한 시작 및 종료 브레이스는 K&R 스타일에 비해 적용상 일관성이 있으며(둘 다 코드 라인과 공간을 공유함), 한 브레이스는 코드 라인과 공간을 공유하고 한 브레이스는 라인만 가지고 있다는 장점이 있습니다.

래틀리프 스타일

Programmers at [33]Work라는 책에서 C.웨인 래틀리프는 아래의 스타일을 사용하는 것에 대해 논의했다.스타일은 1TBS와 거의 비슷하지만 닫힘 괄호는 중첩된 블록의 들여쓰기에 맞춰집니다.Ratlif는 인기 있는 dBase-II 및 -II 4세대 프로그래밍 언어의 원조 프로그래머였습니다.그는 이것이 원래 Digital Research Inc.의 자료로 문서화되어 있었다고 지적했다.이 스타일은 때때로 깃대에 매달린 깃발과 비슷하기 때문에 깃발 [34]스타일로 불린다.K&R이 Allman과 마찬가지로 Whitesmith에 대해서도 마찬가지인 이 스타일에서는 클로징 컨트롤이 목록의 마지막 항목으로 들여쓰기됩니다(따라서 적절하게 salience가 손실됩니다).이 스타일은 어떤 블록의 헤더가 그 레벨에서 유일하게 확장되어 있기 때문에 비주얼 스캔을 용이하게 할 수 있습니다(이전 블록의 클로즈 제어가 K&R 스타일과 Allman 스타일에서 다음 블록 헤더의 비주얼 플로우를 방해한다는 이론).Kernighan과 Plauger는 소프트웨어 [35]도구의 Ratfor 코드에서 이 스타일을 사용합니다.

 // 입력 C  위해서 (i = 0; i < > 10; i++) {      한다면 (i % 2 == 0) {          어떻게 좀 해봐.(i);          }      또 다른 {          다른 것을 해라.(i);          }      } 

마크업 언어로...

{ - 많은 것... 짧은 회선 등을 대신하는 것.}  {   - ...기타 }

리스프 스타일

프로그래머는 블록의 마지막 줄에 닫는 가새까지 삽입할 수 있습니다.이 스타일은 코드 블록을 구분하는 유일한 방법으로 들여쓰기를 사용하지만, 도움이 되지 않는 행을 포함하지 않는다는 장점이 있습니다.이것은 Lisp 스타일(Lisp 코드에서는 이 스타일이 매우 일반적이기 때문에) 또는 Python 스타일(Python은 괄호가 없지만 아래 코드 블록에서 볼 수 있듯이 레이아웃은 매우 유사합니다)이라고 불릴 수 있습니다.Python에서 레이아웃은 오프사이드 규칙이라고 불리는 언어의 일부입니다.

// 입력 C 위해서 (i = 0; i < > 10; i++)     {한다면 (i % 2 == 0)         {어떻게 좀 해봐.(i);}      또 다른         {다른 것을 해라.(i);          세 번째 작업(i);}} 

# Python의 경우 위해서 i  범위(10):     한다면 i % 2 == 0:         무엇인가 하다(i)     또 다른:         do_something_something_something(i)         do_third_thing(세 번째)(i) 

;; 리스프어 (닷타임 (i 10)     (한다면 (= (기억하다 i 2) 0)         (어떤 일을 하다 i)         (예후             (무언가를 하다 i)             (제삼의 일 i)))) 

해스켈 스타일

언어에서는 [36]중괄호와 세미콜론을 사용할 수 있지만 Haskell 레이아웃은 중괄호의 배치를 옵션으로 할 수 있습니다.다음 2개의 세그먼트는 컴파일러가 동일하게 사용할 수 있습니다.

브레이스리스 = 하다   본문 <-> 컨텐츠의 취득   허락하다     퍼스트워드 = 머리 $ 단어 본문     빅워드 = 지도 위쪽 퍼스트워드   putStrln 빅워드  버팀목이 있는 = 하다   { 본문 <-> 컨텐츠의 취득   ; 허락하다       { 퍼스트워드 = 머리 $ 단어 본문       ; 빅워드 = 지도 위쪽 퍼스트워드       }   ; putStrln 빅워드   } 

Haskell에서는 레이아웃이 중괄호를 대체할 수 있습니다.일반적으로 절차상 중괄호와 세미콜론은 생략됩니다. do섹션 및 프로그램 텍스트는 일반적으로 사용되지만, 이 스타일은 쉼표 또는 [37]세미콜론으로 구분된 괄호 또는 중괄호로 구성된 목록, 레코드 및 기타 구문 요소에 일반적으로 사용됩니다.키워드 뒤에 코드가 있는 경우where,let, 또는of중괄호와 세미콜론을 생략하면 들여쓰기가 [38]유의합니다.

APL 스타일

APL이 일반적으로 얼마나 간결한지를 보여주는 예로서, 다음은 Game of Life의 단계 함수 구현입니다.

인생{1.3 4=+/+¯1 0 1∘.¯1 0 1¨} 

APL 스타일 C는 APL 코드의 간결한 스타일과 유사하며 [39]구현에서 일반적으로 사용됩니다.이 스타일은 Arthur Whitney에 의해 개척되었고 Arthur 자신의 프로젝트인 K의 구현에 많이 사용되고 있습니다.J프로그래밍 언어도 이 스타일로 구현됩니다.특히 APL의 모든 구현에서 이러한 스타일의 C, 즉 GNU APL과 Dyalog APL을 사용하는 것은 아닙니다.

APL 스타일 C 들여쓰기 외에 일반적으로 이름은 단일 문자 또는 이중 문자로 단축됩니다.여러 줄에 걸친 들여쓰기 및 표현식을 줄입니다.

기타 고려사항

블록 추적 상실

상황에 따라서는 블록 경계를 추적할 수 없게 될 위험이 있습니다.이는 많은 들여쓰기 수준에 중첩된 복합문을 포함하는 코드의 큰 섹션에서 자주 볼 수 있습니다.프로그래머가 거대한 네스트 스테이트먼트의 맨 아래까지 스크롤 할 때, 어느 제어 스테이트먼트가 어디로 가는지 추적하지 못할 수 있습니다.그러나 지나치게 긴 코드는 너무 복잡한 등의 다른 원인이 있을 수 있으며, 이 문제에 직면한 프로그래머는 코드 리팩터링이 장기적으로 도움이 되는지 여부를 고려할 수 있습니다.

오프닝 브레이스를 세는 데 의존하는 프로그래머는 시작 브레이스가 제어문에서 시각적으로 분리되지 않는 K&R과 같은 들여쓰기 스타일에 어려움을 겪을 수 있습니다.블록이 더 짧기 때문에 들여쓰기에 더 의존하는 프로그래머는 K&R과 같이 수직으로 콤팩트한 스타일로부터 더 많은 것을 얻을 수 있습니다.

다음과 같은 제어문을 잃어버리지 않도록 하기 위해for8유닛 폭의 하드탭과 같은 큰 들여쓰기를 사용할 수 있습니다.또, 큰 기능을 작고 읽기 쉬운 기능으로 분할할 수도 있습니다.Linux는 K&R 스타일을 사용하면서 이 방법으로 이루어집니다.

vi 패밀리의 텍스트 에디터에서 블록 경계를 추적하는 한 가지 방법은 텍스트 커서를 중 하나의 중괄호 위에 놓고%그러면 커서가 반대쪽 가새로 이동합니다.텍스트 커서가next키(viz.,n키) 유지된 방향 위치 정보(유무)up또는down이전에 눌렀던 키), 도트 매크로(tmacro,.키)를 사용하여 적절한 코딩 스타일이 지정되면 다음 [40]가새에 텍스트 커서를 배치할 수 있습니다.대신, 다음을 사용하여 블록 경계를 검사합니다.%키를 사용하여 코딩 표준을 적용할 수 있습니다.

다른 방법으로는 닫힘 괄호 뒤에 추가된 인라인댓글을 사용하는 방법이 있습니다.

위해서 (인트 i = 0; i < > ; i++) {     후우(막대기); } //(i)의 경우 
한다면 (x < > 0) {    막대기(후우); } //if (x < 0) 

이 방법의 주요 단점은 여러 위치에 중복된 코드를 유지하는 것입니다.

또 다른 솔루션은 들여쓰기 수준 또는 복합문 구조를 통해 코드 블록을 숨기거나 표시할 수 있는 폴딩 에디터로 구현됩니다.또한 대부분의 편집자는 커서가 대괄호 옆에 있을 때 일치하는 대괄호 또는 중괄호를 강조 표시합니다.

스테이트먼트 삽입

K&R 스타일은 표준 Unix 라인 에디터 사용 시 발생하는 또 다른 일반적인 오류를 방지합니다.제어문과 루프 블록의 개구 브레이스 사이에 잘못 삽입된 스테이트먼트는 루프 본체를 1회 트립으로 한다.

위해서 (인트 i = 0; i < > 10; i++)     앗.(막대기);   /*는 10회 반복되며 i는 0 ~9 */ {     1회만();   /* 프로그래머는 이 작업을 10회 수행하려고 했습니다.*/ } //for (i) ← 이 코멘트는 더 이상 유효하지 않으며 매우 오해의 소지가 있습니다! 

K&R 스타일은 제어문과 오프닝 브레이스를 같은 줄에 유지함으로써 이 문제를 회피합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Zawinski, Jamie (2000). "Tabs versus Spaces: An Eternal Holy War". Retrieved 6 June 2016.
  2. ^ "WordPress Coding Standards". Retrieved 6 June 2016.
  3. ^ Hoffa, Felipe (26 July 2017). "400,000 GitHub repositories, 1 billion files, 14 terabytes of code: Spaces or Tabs?". Medium. Retrieved 9 July 2019.
  4. ^ Miara, Richard J.; Musselman, Joyce A.; Navarro, Juan A. & Shneiderman, Ben (November 1983). "Program Indentation and Comprehensibility" (PDF). Communications of the ACM. 26 (11): 861–867. doi:10.1145/182.358437. S2CID 11767796. Retrieved 3 August 2017.
  5. ^ a b c "The Jargon File". 4.4.7. 29 December 2003. Retrieved 18 August 2014.
  6. ^ Darwin, Ian F. (1988). Checking C programs with Lint. California: O'Reilly and Assosciates. p. 51. ISBN 9780937175309.
  7. ^ a b "1TBS".
  8. ^ "Java Style Guide". Archived from the original on 12 July 2018. Using either "Egyptian" curly braces or C-style curly braces is acceptable
  9. ^ "Egyptian brackets". Foldoc. A humourous [sic] term for K&R indent style, referring to the "one hand up in front, one down behind" pose
  10. ^ "Google JavaScript Style Guide". Braces follow the Kernighan and Ritchie style ("Egyptian brackets") for nonempty blocks and block-like constructs
  11. ^ a b "Brace styles and JavaScript". 7 January 2013. Retrieved 8 November 2018.
  12. ^ 스타일에 대한 자세한 설명은 kernel.org에서 확인할 수 있습니다.
  13. ^ Larabel, Michael. "The Linux Kernel Deprecates The 80 Character Line Coding Style". Phoronix. Phoronix Media. Retrieved 1 May 2022.
  14. ^ Reddy, Achut (30 March 2000). "Java Coding Style Guide" (PDF). Sun Microsystems. Archived from the original (PDF) on 28 February 2006. Retrieved 30 May 2008.
  15. ^ "Java Code Conventions" (PDF). Sun Microsystems. 12 September 1997. Archived from the original (PDF) on 13 May 2008. Retrieved 30 May 2008.
  16. ^ "Code Conventions for the Java Programming Language". Sun Microsystems. 20 March 1997. Retrieved 30 May 2008.
  17. ^ a b Stroustrup, Bjarne (September 2010). "PPP Style Guide" (PDF).
  18. ^ Stroustrup, Bjarne. "C++ Core Guidelines". GitHub. Retrieved 3 November 2018.
  19. ^ a b c Shannon, Bill (19 August 1996). "C Style and Coding Standards for SunOS" (PDF). 1.8. Sun Microsystems, Inc. Retrieved 15 June 2019.
  20. ^ a b Gregg, Brendan. "DTraceToolkit Style Guide". Retrieved 6 February 2015.
  21. ^ Shannon, Bill (9 September 1998). "cstyle.pl". illumos-gate. 1.58. Sun Microsystems, Inc. Retrieved 6 February 2015.
  22. ^ "indent style". The on-line hacker Jargon File. 4.4.7. 29 December 2003. Retrieved 20 March 2022 – via catb.
  23. ^ a b "Formatting Your Source Code". GNU Coding Standards. Retrieved 6 June 2016.
  24. ^ Stallman, Richard (28 October 2002). "My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference)". Retrieved 6 June 2016.
  25. ^ R. 바우만, M.Feliciano, F. L. Bauer, K.Samuelson, Algol 소개, 1964, https://archive.org/details/introductiontoal00baum
  26. ^ W. M. McKeeman, J. Horning 및 D. B. Wortman, A 컴파일러 제너레이터, 1970, https://archive.org/details/compilergenerato00mcke
  27. ^ Ubuntu 18.04에서 GNU intdes 2.2.11 및 GNU Emacs 25.2로 위의 샘플 소스 코드를 테스트했습니다.emacs --no-init-file.
  28. ^ McConnell, Steve (2004). Code Complete: A practical handbook of software construction. Redmond, WA: Microsoft Press. pp. 746–747. ISBN 978-0-7356-1967-8.
  29. ^ "Linux kernel coding style". Retrieved 1 January 2017.
  30. ^ Jensen, Kathleen; Wirth, Niklaus (1974). PASCAL User Manual and Report. Springer-Verlag.
  31. ^ 호르스트만 스타일 가이드
  32. ^ Ohno, Asako (2013). "A methodology to teach exemplary coding style considering students' coding style feature contains fluctuations". 2013 IEEE Frontiers in Education Conference (FIE): 1908–1910. doi:10.1109/fie.2013.6685167. ISBN 9781467352611. S2CID 28385526.
  33. ^ Lammers, Susan (1986). Programmers at Work. Microsoft Press. ISBN 978-0-914845-71-3.
  34. ^ Pattee, Jim. "Artistic Style 2.05 Documentation". Artistic Style. Retrieved 24 April 2015.
  35. ^ Kernighan, Brian W.; Plauger, P. J. (1976). Software Tools. Addison-Wesley.
  36. ^ "The Haskell 98 Report". haskell.org. Retrieved 3 March 2016.
  37. ^ Lipovača, Miran. "Making Our Own Types and Typeclasses". learnyouahaskell.com. Retrieved 3 February 2016.
  38. ^ 해스켈 보고서 1.2(1992), 페이지 131 B.4 "레이아웃"
  39. ^ "The J Incunabulum". jsoftware.com. Retrieved 19 May 2022.
  40. ^ Lamb, Linda. Learning the vi editor. O'Reilly.

외부 링크

탭 및 공백