들여쓰기 방식

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

들여쓰기 방식은 코드의 가독성을 높이기 위해 사용되는 스타일로, 중괄호 배치, 탭 또는 공백 문자 사용, 들여쓰기 크기 등에서 차이를 보인다. K&R, Allman, GNU, Whitesmiths, Horstmann, Pico, Ratliff, Lisp, Haskell, APL 등 다양한 스타일이 존재하며, 각 스타일은 고유한 특징과 장단점을 갖는다. 들여쓰기 크기는 코드 이해도에 영향을 미치며, 자동화 도구를 통해 코드 형식을 일관되게 유지할 수 있다. 복잡한 코드에서는 블록 경계를 놓치기 쉬우므로, 텍스트 편집기의 기능이나 주석, 큰 들여쓰기 등을 활용하여 가독성을 높일 수 있다.

더 읽어볼만한 페이지

소프트웨어 전쟁 - 엔디언
엔디언은 컴퓨터 메모리에 다중 바이트 데이터를 저장하는 방식으로, 큰 단위 바이트가 앞에 오는 빅 엔디언과 작은 단위 바이트가 앞에 오는 리틀 엔디언으로 나뉘며, CPU 종류에 따라 다르지만 빅/리틀 엔디언을 모두 지원하는 바이 엔디언과 2바이트 단위로는 빅 엔디언, 1바이트 단위로는 리틀 엔디언인 미들 엔디언도 존재한다.
소프트웨어 전쟁 - 브라우저 전쟁
브라우저 전쟁은 1990년대 후반부터 2010년대까지 웹 브라우저 시장에서 경쟁이 치열했던 시기를 의미하며, 넷스케이프 내비게이터와 인터넷 익스플로러의 경쟁으로 시작하여 구글 크롬의 등장과 우위 확보로 마무리되었다.
문서 편집기 기능 - 전문 검색
전문 검색은 문서 내 특정 단어나 구절을 찾는 정보 검색의 핵심 기술로, 인덱싱, 페이지랭크 알고리즘, 문자열 추출 방법, 문서 필터 기술, 질의 도구 개선 등을 통해 발전해왔으며, 웹 검색, 기업용 검색, 데스크톱 검색 등 다양한 분야에서 활용된다.
문서 편집기 기능 - 맞춤법 검사기
맞춤법 검사기는 텍스트의 오타와 문법 오류를 검사하여 수정 제안을 제공하는 소프트웨어 도구이며, 1970년대에 처음 등장하여 기술 발전을 거쳐 현재 다양한 플랫폼에서 여러 언어를 지원한다.
소스 코드 - 헤더 파일
헤더 파일은 프로그래밍 언어에서 코드 재사용성, 모듈화, 컴파일 시간 단축에 기여하며 함수 프로토타입, 변수 선언 등을 포함하고 `#include` 지시어로 소스 코드에 포함되어 사용되는 파일이다.
소스 코드 - 헝가리안 표기법
헝가리안 표기법은 변수 이름에 데이터 타입이나 목적을 나타내는 접두사를 붙이는 명명 규칙으로, 찰스 시모니가 고안하여 마이크로소프트에서 널리 사용되었으나, 코드 가독성 향상에 대한 유용성 논란과 함께 최신 IDE 환경에서는 불필요하다는 비판도 있다.

들여쓰기 방식
개요
종류	스타일 지정 규칙
용도	소스 코드의 가독성 향상
일반적인 방법	공백 또는 탭 삽입
들여쓰기 스타일
일반적인 스타일	Allman 스타일 GNU 스타일 K&R 스타일 Java 스타일 Whitesmiths 스타일 세미 들여쓰기 스타일

2. 주요 들여쓰기 방식

이 문서는 주로 자유 형식 프로그래밍 언어의 스타일에 대해 다룬다. 이름에서 알 수 있듯이, 이러한 언어 코드는 특정 들여쓰기 스타일을 따를 필요가 없다. 들여쓰기는 프로그래머가 코드의 구조를 이해하는 데 드는 인지 부하를 줄이기 위한 보조 표기법이다. 들여쓰기는 제어 흐름에 따라 실행되는 코드 사이의 분리를 명확하게 해준다.

파이썬과 옥캠과 같은 일부 구조적 언어는 중괄호나 키워드를 사용하는 대신 들여쓰기를 사용하여 코드 블록의 구조를 결정하는데, 이를 오프사이드 규칙이라고 한다. 이러한 언어에서 들여쓰기는 컴파일러나 인터프리터에 의해 해석되므로 단순한 스타일을 넘어 문법적인 의미를 가진다. 프로그래머는 언어의 들여쓰기 규칙을 따라야 하지만, 들여쓰기 크기는 자유롭게 선택할 수 있다.

이 문서는 주로 중괄호를 사용하여 코드 블록을 구분하는 언어, 특히 C 계열 언어에 초점을 맞추고 있다. 하지만 한 언어에서 사용되는 들여쓰기 관례는 다른 언어에도 적용될 수 있다. 예를 들어, 중괄호 대신 `BEGIN`과 `END` 키워드를 사용하는 언어는 `BEGIN`을 여는 중괄호처럼 취급하여 유사한 스타일을 적용할 수 있다.

들여쓰기 스타일은 텍스트 기반 언어에만 적용되며, 시각적 프로그래밍 언어는 들여쓰기를 사용하지 않는다.

들여쓰기 스타일이 널리 사용됨에도 불구하고, 그 효과에 대한 연구는 비교적 적었다. 1974년 Weissman이 수행한 초기 실험에서는 들여쓰기의 유의미한 효과가 나타나지 않았다.^[1] 그러나 2023년 Morzeck 등의 실험^[2]에서는 중첩된 `if` 문에 대해 긍정적인 효과가 나타났으며, 들여쓰기되지 않은 코드를 읽는 데 평균 179% 더 많은 시간이 소요되었다. Hanenberg 등의 후속 실험^[3]에서도 큰 효과가 확인되었고(들여쓰기되지 않은 코드는 읽는 데 113% 더 많은 시간 소요), 이 차이는 들여쓰기된 코드에서 특정 부분을 건너뛸 수 있기 때문으로 분석되었다. JSON 객체를 대상으로 한 또 다른 실험^[4]에서는 들여쓰기되지 않은 코드가 읽는 데 544% 더 많은 시간이 걸리는 것으로 나타났다.

C, C++ 등 중괄호를 사용하는 프로그래밍 언어의 코딩 스타일은 주로 다음과 같은 요소에서 차이를 보인다.

다른 코드 요소에 대한 중괄호의 배치
탭 문자 또는 공백 문자 사용 여부 및 개수 (들여쓰기 크기)
단일 문장으로 이루어진 블록을 중괄호로 묶을지 여부. 중괄호를 항상 사용하는 측은 문장 삽입 시 제어 흐름 오류를 방지하여 코드가 더 안전해진다고 주장한다. 반면, 코드가 더 길어진다는 단점이 있다 (`else if` 구조나 `do {} while` 블록 제외).

다음 표는 다양한 들여쓰기 스타일의 코드 예시를 보여준다. 일관성을 위해, 각 스타일의 실제 관례와 관계없이 예시 코드의 들여쓰기 크기는 4칸 공백으로 통일되었다. 각 스타일에 대한 자세한 설명은 해당 하위 섹션에서 다룬다.

괄호 배치	스타일
	올먼
	K&R
	GNU
	화이트스미스
	호르스트만
	Haskell
	Pico
	래트리프
	Lisp

2. 1. K&R 스타일

'''K&R 스타일'''은 브라이언 커니핸과 데니스 리치가 함께 쓴 책 『C 프로그래밍 언어』(흔히 'K&R'로 불림)에서 사용된 들여쓰기 방식으로, C 언어 계열 프로그래밍 언어에서 널리 사용되는 스타일 중 하나이다.^[17] 이 스타일은 초창기 유닉스 커널 소스 코드 작성에도 사용되었다.

K&R 스타일의 주요 특징은 다음과 같다.

함수 정의 시: 여는 중괄호 `{`는 함수 이름이 선언된 다음 줄의 맨 앞에 위치하며, 함수 선언과 같은 들여쓰기 수준을 가진다. 닫는 중괄호 `}`도 함수 선언과 같은 들여쓰기 수준으로 새 줄에 작성된다. 함수 본문 내의 문장들은 추가로 들여쓰기된다.
제어문 (if, for, while 등) 사용 시: 여는 중괄호 `{`는 제어문 키워드 (예: `while (x == y)`)와 같은 줄 끝에 위치한다. 블록 안의 문장들은 추가로 들여쓰기되며, 닫는 중괄호 `}`는 제어문과 같은 들여쓰기 수준으로 새로운 줄에 작성된다. 다만, `else`나 `while` 키워드가 바로 뒤따르는 경우에는 닫는 중괄호와 같은 줄에 이어서 작성하기도 한다.

다음은 K&R 스타일로 작성된 코드 예시이다.

```c

int main(int argc, char *argv[])

{

while (x == y) {

do_something();

do_something_else();

if (some_error)

fix_issue(); // K&R 원본 스타일에서는 단일 문장 블록에 중괄호를 사용하지 않는 경우가 많다.

else

continue_as_usual();

}

final_thing();

}

```

『C 프로그래밍 언어』 책에서는 특정 스타일을 강요하지는 않았지만, 다음과 같이 언급하며 일관된 스타일 사용의 중요성을 강조했다.

::중괄호의 위치는 덜 중요하지만, 사람들은 열정적인 믿음을 가지고 있습니다. 우리는 몇 가지 인기 있는 스타일 중 하나를 선택했습니다. 자신에게 맞는 스타일을 선택한 다음 일관되게 사용하십시오.

K&R 스타일은 제어문과 여는 중괄호가 같은 줄에 있어 코드를 세로로 압축하는 효과가 있다. 이는 과거 화면 공간이 제한적이었던 환경에서 유용했다. 또한, 제어문 바로 다음에 실수로 코드를 삽입하여 발생하는 논리 오류를 방지하는 데 도움이 될 수 있다.^[45] 예를 들어, `while` 문과 여는 중괄호 `{` 사이에 코드를 잘못 추가해도, 중괄호 안의 코드는 여전히 `while` 루프에 속하게 된다.

반면, 여는 중괄호가 제어문과 같은 줄에 있어 블록의 시작점을 명확히 인지하기 어렵다는 의견도 있다. 특히 중첩된 구조가 많을 경우 가독성이 떨어질 수 있다. 또한, K&R 원본 스타일처럼 단일 문장 블록에 중괄호를 생략할 경우, 코드를 수정하는 과정에서 goto fail 버그와 같은 예상치 못한 오류가 발생할 위험이 있다.

K&R 스타일은 이후 등장한 여러 들여쓰기 스타일의 기초가 되었으며, 다양한 변형이 존재한다. 대표적인 변형으로는 1TBS, 리눅스 커널 스타일, 자바 스타일, 스트롭스트룹 스타일, BSD KNF 스타일 등이 있다. 이들은 K&R 스타일의 기본 구조를 따르면서 중괄호 사용 규칙이나 들여쓰기 방식 등에서 약간의 차이를 보인다.

한국의 많은 개발자, 특히 C나 C++ 개발자들 사이에서 K&R 스타일 및 그 변형들이 널리 사용되고 선호되는 경향이 있다.

2. 1. 1. 1TBS (OTBS)

'''One True Brace Style'''^[8] (약칭 '''1TBS''' 또는 '''OTBS'''^[9])는 K&R 스타일과 유사한 들여쓰기 방식이다. 가장 큰 특징은 함수를 선언할 때 여는 중괄호를 함수 이름과 같은 줄에 두며, 제어문 다음에 오는 코드 블록이 단 하나의 문장으로 이루어져 있더라도 중괄호를 생략하지 않는다는 점이다.^[10]

다음은 1TBS 스타일로 작성된 코드 예시이다.

bool is_negative(int x) {

if (x < 0) {

return true;

} else {

return false;

}

}

C나 C++ 같은 언어에서는 문법적으로 단일 문장 블록에 중괄호를 쓰지 않아도 되지만, 1TBS처럼 중괄호를 항상 사용하면 코드 유지보수 과정에서 실수를 줄이는 데 도움이 된다. 예를 들어, 중괄호가 없는 단일 문장 블록 위에 새로운 코드를 추가할 경우, 기존 코드의 실행 흐름이 의도치 않게 변경될 수 있다. 애플에서 발생했던 goto fail 버그는 이러한 위험성을 보여주는 대표적인 사례이다. 1TBS는 이러한 종류의 오류를 예방하여 코드의 안정성을 높이는 장점이 있다.

1TBS의 다른 장점으로는 다음과 같은 점들이 꼽힌다.^[29]

여는 중괄호가 새로운 줄을 차지하지 않아 K&R 스타일에 비해 코드가 세로로 짧아진다.
닫는 중괄호가 해당 코드 블록이 시작된 제어문과 같은 들여쓰기 수준에 위치하여 가독성을 높인다.
함수 본문과 여러 줄로 이루어진 구문 블록 모두 동일한 중괄호 스타일을 적용하여 일관성을 유지한다.

다만, 단일 문장 블록에도 중괄호를 사용하기 때문에, 중괄호를 생략하는 스타일에 비해서는 코드 줄 수가 늘어날 수 있다.

한편, 'One True Brace Style'이라는 용어의 정확한 의미에 대해서는 자료마다 설명이 조금씩 다르다. 일부 자료는 여기서 설명한 것처럼 K&R 스타일의 특정 변형을 가리킨다고 설명하는 반면^[10], 다른 자료에서는 단순히 K&R 스타일을 가리키는 "해커들의 속어"라고 보기도 한다.^[11]

2. 1. 2. 리눅스 커널 스타일

리눅스 커널 소스 코드는 K&R 스타일의 변형을 따르며,^[12]^[47] 리누스 토르발스는 모든 기여자에게 이 스타일을 따를 것을 강력히 권장한다. 주요 특징은 다음과 같다.

들여쓰기에는 공백 대신 탭 문자를 사용하며, 탭 간격은 8칸으로 설정한다.
중괄호 `{}`의 사용 방식은 K&R 스타일과 유사하다.
함수의 시작을 알리는 여는 중괄호 `{`는 함수 이름이 선언된 다음 줄의 맨 앞에 위치시킨다.
함수 본문 내의 제어문(if, while, for 등)에서는, 여는 중괄호 `{`를 제어문과 같은 줄 끝에 둔다. 닫는 중괄호 `}`는 새로운 줄에 작성한다.
`switch 문` 안의 `case`, `default` 레이블은 `switch` 키워드와 같은 들여쓰기 수준으로 정렬한다 (즉, 추가 들여쓰기를 하지 않는다).
한 줄의 최대 길이는 100자로 제한되지만, 2020년 이전의 80자 제한을 따르는 것이 여전히 권장된다.^[13]
`if`, `while`, `do-while` 등 복합문의 본문이 단 하나의 문장으로 이루어진 경우, 중괄호를 사용하지 않아도 된다. 하지만 `if-else` 문에서 `if` 블록이나 `else` 블록 중 어느 한쪽이라도 중괄호가 필요하다면, 양쪽 모두 중괄호로 묶어야 한다.

다음은 리눅스 커널 스타일로 작성된 코드의 예시이다.

```c

int power(int x, int y)

{

int result;

if (y < 0) {

result = 0;

} else {

result = 1;

while (y-- > 0)

result *= x;

}

return result;

}

2. 1. 3. 자바 스타일

자바 코드에서 널리 사용되는 들여쓰기 방식은 K&R 스타일의 변형 중 하나이다. 이 스타일은 함수 내부의 코드 블록뿐만 아니라, 클래스나 메서드를 선언할 때도 여는 중괄호 `{`를 선언문과 같은 줄에 위치시키는 것이 특징이다. 이는 함수 정의 시 여는 중괄호를 다음 줄 첫 칸에 두는 전통적인 K&R 스타일과 구별되는 점이다.

이 방식이 널리 퍼지게 된 계기는 썬 마이크로시스템즈(Sun Microsystems)가 1995년에 발표하고 1999년 4월 20일에 최종 개정한 공식 코딩 규약인 "''자바 프로그래밍 언어 코딩 규칙''"(Code Conventions for the Java Programming Language^eng)에서 이 K&R 변형 스타일을 표준으로 채택했기 때문이다.^[14]^[15]^[16]^[48] 이 영향으로 자바 API의 표준 소스 코드 대부분이 이 스타일을 따르고 있다.

자바 외에도 액션스크립트나 자바스크립트와 같은 ECMAScript 기반 언어에서도 이 스타일이 자주 사용된다.

아래는 자바 스타일의 예시 코드이다.

class Test {

public static void main(String[] args) {

if (args.length > 0) {

// 코드를 작성한다

} else {

// 다른 코드를 작성한다

}

}

}

2. 1. 4. 스트롭스트룹 스타일

스트롭스트룹 스타일은 비야네 스트롭스트룹이 C++에서 사용한 K&R 스타일의 변형으로, 그의 저서인 ''프로그래밍: C++를 사용한 원리 및 실습''과 ''C++ 프로그래밍 언어'' 등에서 사용되었다.^[17]

다른 K&R 변형들과 달리, 스트롭스트룹 스타일은 "cuddled else" (닫는 중괄호 `}`와 `else` 키워드를 같은 줄에 두는 방식)를 사용하지 않는다. 따라서 다음과 같이 작성한다.^[17]

if (x < 0) {

puts("Negative");

negative(x);

}

else {

puts("Non-negative");

nonnegative(x);

}

스트롭스트룹은 K&R 스타일을 클래스 정의에도 확장하여 적용했다. 클래스 내부의 `public:`이나 `private:` 같은 접근 제어 레이블은 들여쓰기하지 않는다. 또한, 함수 정의 시에는 여는 중괄호 `{`를 함수 선언 다음 줄에 두지만, 클래스 정의 시에는 여는 중괄호를 클래스 이름과 같은 줄에 둔다.

class Vector {

public:

// Vector 생성자

Vector(int s) :elem(new double[s]), sz(s) { }

// 요소 접근: 인덱싱

double& operator[](int i) { return elem[i]; }

int size() { return sz; }

private:

// 요소들을 가리키는 포인터

double * elem;

// 요소들의 개수

int sz;

};

스트롭스트룹 스타일에서는 짧은 함수를 한 줄에 작성하는 것을 허용한다. 이 스타일은 텍스트 편집기 Emacs에서도 지원하는 명명된 들여쓰기 스타일 중 하나이다. 스트롭스트룹은 그의 최신 저작인 ''C++ Core Guidelines''에서도 C++ 코드 작성 시 K&R 스타일에서 파생된 레이아웃을 사용할 것을 권장하고 있다.^[18]

2. 1. 5. BSD KNF 스타일

BSD 운영 체제에서 사용되는 스타일로, 때때로 커널 노멀 폼 (KNF)이라고도 불린다. 주로 커널 코드를 위해 사용되지만, 유저랜드 코드에서도 널리 사용된다. 이는 본질적으로 벨 연구소 버전 6 및 7 유닉스 소스 코드에서 사용된 K&R 스타일의 철저하게 문서화된 변형이다.^[19]

SunOS 커널과 유저랜드는 유사한 들여쓰기 스타일을 사용한다.^[19] KNF와 마찬가지로, 이것 또한 AT&T 스타일 문서를 기반으로 하며 때때로 '''빌 조이 노멀 폼'''이라고 불린다.^[20] SunOS 가이드라인은 1996년에 발표되었으며, ANSI C에 대해 간략하게 논의한다. 소스 파일 목록의 들여쓰기 정확성은 빌 섀넌이 작성한 ''cstyle'' 프로그램으로 확인할 수 있다.^[19]^[20]^[21]

이 스타일에서 하드 탭(vi에서 `ts`)은 8열로 유지되며, 소프트 탭도 종종 보조 도구(vi에서 `sw`)로 정의되어 4로 설정된다. 하드 탭은 코드 블록을 들여쓰는 데 사용되며, 여러 줄로 분할해야 하는 모든 연속 줄에 추가 들여쓰기로 소프트 탭(4개의 공백)이 사용된다.

또한 함수 호출은 괄호 앞에 공백을 사용하지 않지만, `if`, `while`, `do`, `switch` 및 `return`과 같은 C 언어 기본 문은 (return이 괄호와 함께 사용되는 경우) 사용한다. 최상위 블록에서 지역 변수를 선언하지 않는 함수는 여는 블록 중괄호 뒤에 빈 줄을 남겨야 한다.

다음은 그 예시이다:

while (x == y) {

something();

something_else();

}

final_thing();

if (data != NULL && res > 0) {

if (JS_DefineProperty(cx, o, "data",

STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)),

NULL, NULL, JSPROP_ENUMERATE) != 0) {

QUEUE_EXCEPTION("Internal error!");

goto err;

}

PQfreemem(data);

} else {

if (JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL),

NULL, NULL, JSPROP_ENUMERATE) != 0) {

QUEUE_EXCEPTION("Internal error!");

goto err;

}

}

static JSBool

pgresult_constructor(JSContext *cx, JSObject *obj, uintN argc,

jsval *argv, jsval *rval)

{

QUEUE_EXCEPTION("PGresult class not user-instantiable");

return (JS_FALSE);

}

2. 2. 올먼 스타일 (BSD/Allman)

올먼 스타일은 에릭 올먼의 이름을 따서 명명되었으며, 올먼이 BSD 유닉스용 유틸리티를 많이 작성했기 때문에 BSD 스타일이라고도 불린다.

이 스타일은 제어문의 중괄호를 제어문과 같은 수준으로 들여쓰기된 다음 줄에 위치시킨다. 중괄호 안의 문장들은 다음 단계로 들여쓰기된다.^[11]^[54]

```c

while (x == y)

{

something();

something_else();

}

final_thing();

```

이 방식은 중괄호를 `begin`과 `end` 키워드처럼 취급하는 파스칼 언어나 Transact-SQL에서 사용되는 표준 들여쓰기와 유사하다.

```pascal

(* 파스칼의 올먼 스타일 코드 들여쓰기 예시 *)

procedure dosomething(x, y: Integer);

begin

while x = y do

begin

something();

something_else();

end;

end;

```

올먼 스타일의 장점은 다음과 같다.

들여쓰기된 코드가 중괄호만 있는 줄로 명확하게 구분되어 블록 구조를 파악하기 쉽다.
여는 중괄호와 닫는 중괄호가 같은 열에 위치하여 서로 짝을 맞추기 용이하다.
코드 블록과 관련된 제어문을 시각적으로 분리한다.
제어문이나 코드 블록을 주석 처리하거나 제거하는 등 코드 리팩토링을 할 때, 중괄호 위치로 인한 구문 오류가 발생할 가능성이 줄어든다. 예를 들어 아래와 같이 제어문을 주석 처리해도 코드 블록 자체는 문법적으로 유효하다.

```c

// while (x == y)

{

something();

something_else();

}

```

함수 정의 시 중괄호 배치 방식과 일관성을 유지한다.
조건부 컴파일 지시자를 사용할 때도 코드 구조를 명확하게 유지하는 데 도움이 된다.

```c

int c;

#ifdef HAS_GETCH

while ((c = getch()) != EOF)

#else

while ((c = getchar()) != EOF)

#endif

{

do_something(c);

}

```

이 스타일은 제어문과 코드 블록을 명확히 분리하여 가독성을 높이는 것을 중요하게 생각한다. 마이크로소프트는 C# 코딩 규칙에서 이 스타일을 권장하며^[55], Microsoft Visual Studio의 기본 서식 스타일 중 하나이기도 하다.

```csharp

// C# 예시 코드

if ((val1 > val2) && (val1 > val3))

{

something();

}

2. 2. 1. Allman-8

Allman-8은 올먼 스타일의 변형으로, K&R 스타일의 리눅스 커널 변형에서 사용하는 8칸 들여쓰기 탭과 80열 제한을 따른다.

Allman-8 스타일은 특히 프로젝터로 코드를 보여줄 때 가독성을 높이는 데 도움이 된다고 알려져 있다. 또한 넓은 들여쓰기 폭과 엄격한 열 제한은 코드 블록이 지나치게 깊게 중첩되는 것을 시각적으로 쉽게 파악하게 해준다. 이러한 특징 덕분에 코드를 처음 배우는 학습자나 신입 개발자가 코드의 복잡도를 관리하는 데 유용하며, 이로 인해 미국의 교육 현장에서 자주 사용되기도 한다.

2. 3. 화이트스미스 스타일

화이트스미스 스타일(Whitesmiths style)은 때때로 위셔트 스타일(Wishart style)이라고도 불리며, 최초의 상업용 C 컴파일러인 Whitesmiths 컴파일러의 문서에서 사용된 방식이다. 또한 초기 윈도우 시대에 인기가 있었는데, 이는 ''Programmer's Guide to Windows''(듀란트, 칼슨, 야오 공저), ''Programming Windows''(펫졸드 저), ''Windows 3.0 Power Programming Techniques''(노튼, 야오 공저) 등 3권의 영향력 있는 윈도우 프로그래밍 서적에서 사용되었기 때문이다.

화이트스미스 스타일은 Allman 스타일과 함께 1991년 Jargon File에서 가장 흔한 중괄호 스타일로 언급되었으며, 당시 두 스타일의 인기는 거의 비슷했다.^[11]^[22]

이 스타일은 제어문과 관련된 중괄호를 다음 줄에 들여쓰기하여 배치한다. 중괄호 내의 문장은 중괄호와 같은 수준으로 들여쓰기된다.^[28]

while (x == y)

{

something();

something_else();

}

final_thing();

이 스타일의 장점은 Allman 스타일과 유사하게 블록이 제어문과 명확하게 구분된다는 점이다. 또한, 중괄호와 그 안의 문장들을 같은 들여쓰기 수준으로 배치하여 전체 블록이 개념적으로 하나의 복합 문장임을 강조한다. 중괄호를 들여쓰기함으로써 중괄호가 제어문에 종속됨을 강조하며, 문법적으로도 제어문의 일부가 아닌 복합문의 일부임을 나타낸다.

단점으로는 중괄호가 눈에 잘 띄지 않을 수 있다는 지적이 있다. 하지만, 중괄호만으로 한 줄을 차지하기 때문에, 눈에 띄는지는 의견이 분분하다. 또한 다른 스타일과 마찬가지로 코드가 복잡하게 중첩될 경우 프로그래머가 블록의 경계를 놓치기 쉬울 수 있다.

다음은 화이트스미스 스타일로 작성된 코드의 예시이다.

if (data != NULL && res > 0)

{

if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)), NULL, NULL, JSPROP_ENUMERATE))

{

QUEUE_EXCEPTION("Internal error!");

goto err;

}

PQfreemem(data);

}

else if (!JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL), NULL, NULL, JSPROP_ENUMERATE))

{

QUEUE_EXCEPTION("Internal error!");

goto err;

}

이 스타일에서는 `else if`를 하나의 문장으로 취급하며, 이는 전처리기 지시문 `#elif`와 유사한 방식으로 다루어진다.

2. 4. GNU 스타일

Allman 스타일과 Whitesmiths 스타일처럼, '''GNU 스타일'''은 중괄호를 별도의 줄에 배치하지만, 두 칸 들여쓰기를 한다. 다만 함수 정의를 시작하는 경우에는 중괄호를 들여쓰기하지 않는다.^[23]^[56] 어떤 경우든 중괄호 안의 코드는 중괄호에서 두 칸 더 들여쓴다.

리처드 스톨먼이 널리 사용하고 알린 이 스타일은 그가 Lisp 코드를 작성한 경험에서 영향을 받았을 수 있다.^[24]^[57] Lisp에서 블록(progn)에 해당하는 것은 일급 데이터 엔터티이며, 자체 들여쓰기 수준을 부여하면 이를 강조하는 데 도움이 된다. 반면 C에서 블록은 단지 구문일 뿐이다. 이 스타일은 1960년대와 1970년대의 일부 ALGOL 및 XPL 프로그래밍 언어 교과서에서도 찾아볼 수 있다.^[25]^[26]^[58]^[59] 들여쓰기와 직접적인 관련은 없지만, GNU 코딩 스타일은 함수 이름 뒤와 인수 목록의 왼쪽 괄호 앞에 공백을 포함하는 특징도 있다.^[23]

static char *

concat (char *s1, char *s2)

{

while (x == y)

{

something ();

something_else ();

}

final_thing ();

}

이 스타일은 Allman 스타일과 Whitesmiths 스타일의 장점을 일부 결합한 것으로 평가받으며, 특히 Whitesmiths 스타일에서 중괄호가 눈에 잘 띄지 않는다는 단점을 보완한다. 반면, 닫는 중괄호가 그것이 속한 제어문과 시각적으로 정렬되지 않는다는 점, 그리고 하나의 논리적 단계에 두 단계의 시각적 들여쓰기를 사용하여 공간을 낭비할 수 있다는 점이 단점으로 지적되기도 한다. 하지만 실제로는 각 들여쓰기 단계가 보통 최소 4칸 공백인 다른 스타일과 비교할 때, GNU 스타일의 2칸 + 2칸 들여쓰기가 반드시 더 많은 공간을 차지한다고 보기는 어렵다.

GNU 코딩 표준은 이 스타일을 권장하며, GNU 프로젝트 관련 소프트웨어 개발자 대부분이 이 스타일을 따른다. GNU Emacs 텍스트 편집기와 GNU 시스템의 indent 명령은 기본적으로 이 스타일에 맞춰 코드를 자동으로 정렬하는 기능을 제공한다.^[27] 다른 편집기에서는 자동 들여쓰기 설정이 이 스타일에 맞지 않을 수 있지만, 탭 너비를 2칸으로 설정하면 어느 정도 호환될 수 있다.

스티브 맥코넬은 그의 저서 Code Complete에서 이 스타일의 사용을 권장하지 않으며, 가독성을 해칠 수 있다고 평가했다.^[28] 또한 리눅스 커널 코딩 스타일 가이드라인에서도 이 스타일에 대해 비판적인 입장을 보이며 다른 스타일 사용을 권장한다.^[29]

2. 5. 호르스트만 스타일

1997년 카이 호르스트만이 저술한 ''C++로 배우는 컴퓨팅 개념''에서는 올먼 스타일의 변종이 사용되었는데, 블록의 머리에서 중괄호를 열고 같은 행에 첫 번째 문장을 위치시키는 방식이다. 이 스타일은 옌센과 비르트가 쓴 ''파스칼 사용자 매뉴얼 및 보고서''^[60]에서도 사용되었다.

while (x == y)

{ something();

somethingelse();

//...

if (x < 0)

{ printf("Negative");

negative(x);

}

else

{ printf("Non-negative");

nonnegative(x);

}

}

finalthing();

이 스타일은 올먼 스타일의 장점인 가독성(중괄호의 세로 정렬을 유지하여 블록 식별이 용이하다)과 K&R 스타일처럼 한 줄을 절약할 수 있는 장점을 결합한 것으로 평가받는다. 하지만 호르스트만의 2003년 개정판에서는 전면적으로 올먼 스타일이 채택되었다.^[61]

2. 6. 피코 스타일

주로 Pico 언어에서 사용되는 스타일이다.^[32] Pico 언어는 `return` 문이 없고 세미콜론(;)을 문장 종결자가 아닌 문장 구분자로 사용하는데, 이러한 특징이 코드 스타일에 영향을 준다.

stuff(n):

{ x: 3 * n;

y: doStuff(x);

y + x }

다른 프로그래밍 언어의 제어문에 이 스타일을 적용하면 다음과 같은 형태가 된다. 여는 중괄호(`{`)는 제어문 다음 줄에서 들여쓰기된 첫 코드와 함께 시작하고, 닫는 중괄호(`}`)는 마지막 코드 줄의 끝에 위치한다.

while (x == y)

{ something();

somethingelse(); }

화면 공간을 절약한다는 장점은 K&R 스타일과 유사하다. 추가적인 장점은 여는 중괄호와 닫는 중괄호 모두 코드와 같은 줄에 위치하여 중괄호 사용이 일관적이라는 점이다. 이는 여는 중괄호만 코드와 같은 줄에 두고 닫는 중괄호는 별도 줄에 두는 K&R 스타일과 대조된다.

2. 7. 래트리프 스타일

C. 웨인 래트리프는 저서 ''Programmers at Work''^[33]^[63]에서 이 스타일에 대해 언급했다. 그는 인기 있는 dBase-II 및 -III 4GL의 원 개발자이다. 이 스타일은 1TBS와 유사하지만, 닫는 중괄호}가 제어문 시작 부분이 아닌, 중첩된 코드 블록과 같은 수준으로 들여쓰기된다는 점이 다르다. 래트리프는 이 스타일이 원래 Digital Research Inc.의 자료에 문서화되었다고 밝혔다.

때때로 '배너(Banner)' 스타일이라고도 불리는데,^[34] 이는 닫는 중괄호가 마치 기둥에 걸린 배너처럼 보이기 때문일 수 있다. 이 스타일에서 닫는 제어문(중괄호)은 코드 블록 내 마지막 문장과 동일한 들여쓰기 수준을 갖는다.^[28] 일부 사람들에게는 블록의 시작 부분(헤더)만 해당 들여쓰기 수준에 위치하므로 시각적으로 코드를 훑어보기 더 쉬울 수 있다. 이는 이론적으로 K&R 스타일이나 올먼 스타일에서 이전 블록의 닫는 중괄호가 다음 블록 헤더의 시각적 흐름을 방해할 수 있다는 점과 대비된다.

브라이언 커니핸과 켄 플라우거는 저서 ''소프트웨어 도구''에서 Ratfor 코드를 작성할 때 이 스타일을 사용했다.^[35]

// C 언어 예시

for (i = 0; i < 10; i++) {

if (i % 2 == 0) {

do_something(i);

}

else {

do_something_else(i);

}

}

2. 8. Lisp 스타일

GNU 스타일은 때때로 리스프(Lisp) 프로그래머가 작성한 C 코드처럼 보이기도 하는데, 이는 블록의 마지막 줄에 닫는 중괄호 '}'를 함께 배치하는 특징 때문이다. 이 스타일은 들여쓰기만으로 코드 블록을 구분하게 되지만, 불필요한 빈 줄이 생기지 않는다는 장점이 있다. 리스프 코드에서 매우 흔하게 사용되기 때문에 Lisp 스타일이라고도 불린다.

리스프에서는 표현식 트리의 끝에 여러 닫는 괄호를 한 줄에 모아 적는 경우가 많은데, 이는 사용자가 중첩된 괄호의 개수를 세는 것보다 코드의 전체적인 구조를 파악하는 것이 더 중요하다고 보기 때문이다.

전통적인 Lisp 스타일 변형에서는 들여쓰기 너비를 매우 좁게(보통 공백 2칸) 사용하는 경향이 있다. 이는 리스프 코드가 다른 언어에 비해 중첩 구조가 매우 깊어지는 경우가 많기 때문이다. 리스프는 표현식만 있고 문이라는 별도의 개념이 없다는 점도 깊은 중첩의 한 이유이다. 함수 인수는 대부분 같은 수준으로 들여쓰기하여, 감싸는 표현식 안에서 상태를 공유함을 보여준다. 또한 리스프는 괄호를 제외하면 매우 간결한 언어이므로, C 언어의 `if-else` 구문에서 `else` 키워드처럼 반복적으로 사용되는 코드를 생략하고 `(if 조건식 참일_때 거짓일_때)`와 같이 통일된 형태로 표현한다.

아래는 C 코드와 Lisp 코드의 스타일 차이를 보여주는 예시이다.

// C

for (i = 0; i < 10; i++)

{if (i % 2 == 0)

{do_something(i);}

else

{do_something_else(i);

do_third_thing(i);}}

;; Lisp

(dotimes (i 10)

(if (= (rem i 2) 0)

(do-something i)

(progn

(do-something-else i)

(do-third-thing i))))

^{참고: `progn`은 여러 하위 표현식을 순서대로 평가하여 부작용을 일으키고 마지막 표현식의 값만 반환하는 함수이다. 모든 반환 값이 필요하면 `values` 함수를 사용한다.}

다음은 C 언어에서 Lisp 스타일을 적용한 예시이다.

while (x == y)

{ foo();

bar(); }

2. 9. Haskell 스타일

Haskell의 레이아웃 규칙은 중괄호 배치를 선택적으로 만든다. 즉, 중괄호와 세미콜론을 사용하는 것이 언어 문법상 허용되지만, 반드시 필요한 것은 아니다.^[36]

아래 두 코드 예시는 Haskell 컴파일러가 동일하게 인식한다. 첫 번째는 중괄호와 세미콜론 없이 레이아웃(들여쓰기) 규칙을 따른 것이고, 두 번째는 명시적으로 중괄호와 세미콜론을 사용한 것이다.

braceless = do

text <- getContents

let

firstWord = head $ words text

bigWord = map toUpper firstWord

putStrLn bigWord

braceful = do

{ text <- getContents

; let

{ firstWord = head $ words text

; bigWord = map toUpper firstWord

}

; putStrLn bigWord

}

Haskell에서 레이아웃 규칙은 중괄호를 대체하는 역할을 한다. 일반적으로 절차적 스타일의 do 블록이나 일반적인 프로그램 코드에서는 중괄호와 세미콜론을 생략하는 경우가 많다. 하지만 쉼표나 세미콜론으로 구분되는 리스트, 레코드 정의 등에서는 괄호나 중괄호를 사용하는 것이 일반적이다.^[37]

특히 where, let, of 키워드 뒤에 오는 코드 블록에서는 중괄호와 세미콜론을 생략할 경우, 들여쓰기 자체가 코드의 구조를 결정하는 중요한 문법 요소가 된다.^[38] 이는 오프사이드 규칙의 한 예로, 들여쓰기가 단순히 가독성을 넘어 코드의 의미에 직접적인 영향을 미치는 경우이다.

다른 들여쓰기 스타일과 비교했을 때, Haskell 스타일의 중괄호 사용 예시는 다음과 같이 표현될 수 있다 (단, 실제 Haskell 코드에서는 중괄호가 생략되는 경우가 더 흔하다).

while (x == y)

{ something()

; somethingelse()

;

}

2. 10. APL 스타일

APL 스타일 C는 APL 코드의 간결한 스타일을 모방하여 구현하는 것을 목표로 한다.^[39] APL 언어 자체가 얼마나 간결한지를 보여주는 예로 생명 게임의 단계 함수 구현을 들 수 있다.

```apl

life←{⊃1⍵∨.∧3 4=+/+⌿¯1 0 1∘.⊖¯1 0 1⌽¨⊂⍵}

```

이 스타일은 컴퓨터 과학자 아서 휘트니가 개척했으며, 그의 개인 프로젝트인 K 언어 구현에 널리 사용되었다. J 프로그래밍 언어 역시 이 스타일로 구현되었다. 하지만 모든 APL 구현이 이 스타일의 C 코드를 사용하는 것은 아니며, 예를 들어 GNU APL과 Dyalog APL은 다른 스타일을 사용한다.

APL 스타일 C 코드는 들여쓰기 방식 외에도, 코드의 간결성을 위해 변수나 함수의 이름을 한두 글자로 줄여 사용하는 경향이 있다. 이는 들여쓰기 양을 줄이고 여러 줄에 걸쳐 표현식을 작성하는 데 도움이 된다.^[40] 다음은 APL 스타일 C 코드의 예시이다.

```c

#define W(c,b) {while(c){b}}

W(x==y,f();b();)

3. 들여쓰기 크기 및 자동화

일반적으로 프로그래머는 코드의 각 블록을 들여쓰기 할 때 동일한 너비의 공백을 사용하며, 흔히 1칸에서 4칸 사이의 너비가 사용된다. 1983년에 진행된 파스칼 코드에 대한 실험에서는 들여쓰기 크기가 코드 이해도에 상당한 영향을 미치는 것으로 나타났으며, 2칸에서 4칸 사이의 들여쓰기 크기가 가장 효과적이었다.^[41] 들여쓰기 크기는 코드의 전반적인 배치에 영향을 주지만, 이는 들여쓰기 '스타일' 자체와는 별개의 문제이다.

들여쓰기를 할 때 프로그래머는 탭 문자를 사용하거나, 정해진 너비만큼의 공백 문자를 사용한다. 일반적으로 텍스트 편집기는 일정한 간격(탭 너비)으로 탭 정지점을 제공하여 스타일 유지를 돕는다. 코드에 탭 문자를 저장할지, 아니면 공백 문자를 저장할지에 대해서는 프로그래머들 사이에 합의가 이루어지지 않았다.

탭 문자 사용: 탭 문자를 선호하는 측에서는 여러 공백 대신 하나의 탭 문자를 사용하므로 타이핑이 더 쉽고 텍스트 파일의 크기가 작아진다는 장점을 강조한다. WordPress 코딩 표준과 같이 일부에서는 하드 탭이 오히려 이식성을 높인다고 주장하기도 한다.^[43]
공백 문자 사용: 반면 Jamie Zawinski 등 공백 문자를 선호하는 측에서는 공백을 사용하면 다른 환경에서 코드를 볼 때 시각적인 정렬이 깨지지 않아 크로스 플랫폼 이식성이 높아진다고 주장한다.^[42] GitHub 상위 40만 개 저장소를 조사한 결과에서는 공백 사용이 더 일반적이었다.^[44]

Notepad++, TextEdit, Emacs, vi, nano를 포함한 많은 텍스트 편집기에서는 탭 키 입력 시 탭 문자를 저장할지, 아니면 설정된 너비만큼의 공백 문자로 변환할지 설정할 수 있다. 또한, 탭 문자를 공백 문자로, 또는 그 반대로 변환하는 기능도 제공한다. less와 같은 일부 텍스트 파일 페이저는 표시되는 탭 너비를 조절할 수 있고, expand나 unexpand 같은 유닉스 도구를 사용해 탭과 공백을 서로 변환할 수도 있다.

들여쓰기 스타일에 따라 코드 서식을 자동으로 지정하는 도구도 존재한다. 예를 들어 유닉스의 indent 명령어가 대표적이다. Emacs 같은 편집기는 특정 줄이나 선택 영역의 들여쓰기를 자동으로 수정하는 기능을 제공한다. Elastic tabstops는 텍스트 편집기의 지원이 필요한 탭 스타일로, 블록 내 한 줄의 길이가 바뀌면 해당 블록 전체가 자동으로 정렬 상태를 유지하도록 한다.

참조

_[1] 간행물 A Methodology For Studying The Psychological Complexity of Computer Programs https://archive.org/[...] Computer Systems Research Group, [[University of Toronto]]
_[2] 학회 Indentation in Source Code: A Randomized Control Trial on the Readability of Control Flows in Java Code with Large Effects https://drive.google[...]
_[3] 논문 Indentation and reading time: a randomized control trial on the differences between generated indented and non-indented if-statements 2024-08-09
_[4] 서적 Software Technologies Springer Nature Switzerland 2024
_[5] 웹사이트 Java Style Guide https://www.seas.upe[...]
_[6] 웹사이트 Egyptian brackets http://foldoc.org/Eg[...]
_[7] 웹사이트 Google JavaScript Style Guide https://google.githu[...]
_[8] 서적 Checking C programs with Lint https://google.githu[...] O'Reilly and Assosciates
_[9] 웹사이트 1TBS http://catb.org/jarg[...]
_[10] 웹사이트 Brace styles and JavaScript http://2ality.com/20[...] 2013-01-07
_[11] 웹사이트 The Jargon File http://www.catb.org/[...] 2003-12-29
_[12] 문서 A detailed description of the style is given at [https://www.kernel.org/doc/html/latest/process/coding-style.html kernel.org].
_[13] 웹사이트 The Linux Kernel Deprecates The 80 Character Line Coding Style https://www.phoronix[...] Phoronix Media
_[14] 웹사이트 Java Coding Style Guide http://developers.su[...] Sun Microsystems 2000-03-30
_[15] 웹사이트 Java Code Conventions http://java.sun.com/[...] Sun Microsystems 1997-09-12
_[16] 웹사이트 Code Conventions for the Java Programming Language http://java.sun.com/[...] Sun Microsystems 1997-03-20
_[17] 웹사이트 PPP Style Guide https://www.stroustr[...] 2010-09
_[18] 웹사이트 C++ Core Guidelines https://github.com/i[...]
_[19] 뉴스 C Style and Coding Standards for SunOS https://www.cis.upen[...] Sun Microsystems, Inc. 1996-08-19
_[20] 웹사이트 DTraceToolkit Style Guide http://www.brendangr[...]
_[21] 웹사이트 cstyle.pl https://github.com/i[...] Sun Microsystems, Inc. 1998-09-09
_[22] 웹사이트 The Jargon File (Version 2.4.3) http://www.catb.org/[...] 1991-01-23
_[23] 웹사이트 Formatting Your Source Code https://www.gnu.org/[...]
_[24] 웹사이트 My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference) https://www.gnu.org/[...] 2002-10-28
_[25] 서적 Introduction to ALGOL – A primer for the non-specialist, emphasizing the practical uses of the algorithmic language https://archive.org/[...] [[Prentice-Hall, Inc.]] 1964
_[26] 문서 W. M. McKeeman, J. J. Horning, and D. B. Wortman, A Compiler Generator, 1970, https://archive.org/details/compilergenerato00mcke
_[27] 문서 Tested on the sample source code above on Ubuntu 18.04 with GNU indent 2.2.11 and GNU Emacs 25.2.2 started with emacs --no-init-file.
_[28] 서적 Code Complete: A practical handbook of software construction https://archive.org/[...] Microsoft Press
_[29] 웹사이트 Linux kernel coding style https://www.kernel.o[...]
_[30] 서적 PASCAL User Manual and Report Springer-Verlag
_[31] 문서 '[http://www.horstmann.com/bigcpp/styleguide.html Horstmann Style Guide]'
_[32] 서적 2013 IEEE Frontiers in Education Conference (FIE) 2013
_[33] 서적 Programmers at Work https://archive.org/[...] Microsoft Press
_[34] 웹사이트 Artistic Style 2.05 Documentation http://astyle.source[...]
_[35] 서적 Software Tools https://archive.org/[...] Addison-Wesley
_[36] 웹사이트 The Haskell 98 Report https://www.haskell.[...] 2016-03-03
_[37] 웹사이트 Making Our Own Types and Typeclasses http://learnyouahask[...] 2016-02-03
_[38] 문서 Haskell Report 1.2 (1992), p.131 B.4 "Layout"
_[39] 웹사이트 The J Incunabulum https://www.jsoftwar[...] 2022-05-19
_[40] 웹사이트 The J source code https://github.com/j[...] 2024-09-12
_[41] 논문 Program Indentation and Comprehensibility http://www.cs.umd.ed[...] 2017-08-03
_[42] 웹사이트 Tabs versus Spaces: An Eternal Holy War http://www.jwz.org/d[...] 2016-06-06
_[43] 웹사이트 WordPress Coding Standards http://codex.wordpre[...] 2016-06-06
_[44] 웹사이트 400,000 GitHub repositories, 1 billion files, 14 terabytes of code: Spaces or Tabs? https://medium.com/@[...] 2019-07-09
_[45] 서적 Learning the vi editor https://archive.org/[...] O'Reilly
_[46] 웹사이트 1TBS http://catb.org/jarg[...] 2022-04-15
_[47] 문서 このスタイルについての詳細はここで詳しく示されている[https://www.kernel.org/doc/html/latest/process/coding-style.html kernel.org].
_[48] 문서 Code Conventions for the Java Programming Language: Contents https://www.oracle.c[...]
_[49] 웹사이트 PPP Style Guide https://www.stroustr[...] 2022-04-15
_[50] 웹사이트 C++ Core Guidelines https://github.com/i[...] 2018-11-03
_[51] 뉴스 C Style and Coding Standards for SunOS https://www.cis.upen[...] Sun Microsystems, Inc. 1996-08-19
_[52] 웹사이트 DTraceToolkit Style Guide http://www.brendangr[...] 2015-02-06
_[53] 웹사이트 cstyle.pl https://github.com/i[...] Sun Microsystems, Inc. 2015-02-06
_[54] 웹사이트 indent style http://www.catb.org/[...] 2003-12-29
_[55] 문서 C# のコーディング規則 - C# プログラミングガイド | Microsoft Docs https://docs.microso[...]
_[56] 웹사이트 Formatting Your Source Code https://www.gnu.org/[...] 2016-06-06
_[57] 웹사이트 My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference) https://www.gnu.org/[...] 2016-06-06
_[58] 간행물 Introduction to Algol https://archive.org/[...] 1964
_[59] 간행물 A Compiler Generator https://archive.org/[...] 1970
_[60] 서적 PASCAL User Manual and Report Springer-Verlag
_[61] 문서 Horstmann Style Guide http://www.horstmann[...]
_[62] 논문 学生のコーディングスタイルにばらつきがあることを前提に、模範となるコーディングスタイルを教えるための方法論 2013
_[63] 서적 Programmers at Work https://archive.org/[...] Microsoft Press
_[64] 웹사이트 Artistic Style 2.05 Documentation http://astyle.source[...] 2015-04-24
_[65] 웹사이트 The Haskell 98 Report https://www.haskell.[...] 2016-03-03

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com