위키백과:WikiProject Computer science/Manual of style위키프로젝트 컴퓨터 과학/스타일 설명서

Wikipedia:
"WP:CODE" 리디렉션 Wiki 마크업에 대한 자세한 내용은 도움말:위키 마크업.
스타일 매뉴얼(MoS)
내용
서식
이미지들
배치
목록
합법적
주제 영역별
관련 지침

이 설명서에는 명확하고 즐거운 표정, 그리고 바라건대 흥미로운 컴퓨터 과학 기사를 쓰는 데 기여하기를 바라는 몇 가지 제안이 포함되어 있다. 이 가이드는 위키백과 편집자에게 유용한 정보가 많이 있는 위키백과 스타일의 매뉴얼을 대체하기 위한 것이 아니라 보완을 위한 것이다.

컴퓨터 과학 기사의 제안된 구조

아마도 기술 기사를 쓰면서 가장 어려운 부분은 독자의 입장에서 기술 지식의 수준을 다루는 어려움일 것이다. 일반적인 접근방식은 단순하게 시작한 다음, 기사가 진행됨에 따라 보다 공식적이고 기술적인 진술로 나아가는 것이다.

기사 소개

기사는 주제를 일반적인 용어로 설명하는 도입부(2개)부터 시작해야 한다. 이 첫 단락은 캐주얼한 독자들에게 개념을 빨리 이해시켜 주어야 한다. 이 개념이 속하는 컴퓨터 과학 분야의 이름을 지정하고 이 용어가 사용되는 맥락에 대해 설명하십시오. 기사 제목을 굵게 쓰시오. 역사적 동기를 포함하고, 약간의 이름과 날짜를 제공한다. 여기 예가 있다.

컴퓨터 과학에서 CSP(Communication Sequential Process)는 동시 시스템에서의 상호작용 패턴을 기술하기 위한 공식 언어다. 그것은 프로세스 알제브라, 즉 프로세스 칼쿨리로 알려진 동시성의 수학 이론 계열의 일원이다. CSP는 C에 의해 1978년 논문에서 처음 설명되었다. A. R. Hoare, 그러나 그 이후로 상당히 진화했다. CSP는 다양한 다른 시스템의 동시적 측면을 명시하고 검증하는 도구로서 산업에서 실질적으로 적용되어 왔다. CSP의 이론은 여전히 그 실용성을 높이기 위한 연구를 포함한 적극적인 연구의 대상이다. CSP는 오캄 프로그래밍 언어의 발달에 영향을 미쳤다.

개요 및 동기 부여

비기술적 독자에게 제시되는 주제의 기본 개념에 대한 기본적인 이해를 제공하는 비공식적인 소개로 기사의 주요 부분을 시작하는 것이 좋다. 문제의 개념이 다소 이론적이라면 비공식 서론에서 동기부여나 적용에 관한 섹션을 갖는 것이 도움이 될 수 있다. 또한 몇 가지 대표적인 예를 들 수 있는데, 이는 문제의 개념을 확장시키는 역할을 할 수 있고, 또한 왜 그 개념을 사용하고 싶은지에 대한 문맥도 제공할 수 있다.

그림은 한 점을 본국으로 가져오는 훌륭한 방법이며, 종종 그것은 개념의 기술적인 논의보다 앞서기도 한다. 위키백과 기사의 그래프를 만드는 방법에는 그래프와 다른 그림을 만드는 방법, 그리고 그것들을 기사에 포함하는 방법에 대한 힌트가 있다.

도입 단락에 포함되지 않는 경우, 개념의 역사에 관한 섹션은 종종 유용하며 추가적인 통찰력과 동기를 제공할 수 있다.

다양한 종류의 물품의 구조

컴퓨터 과학은 다양한 종류의 아이디어를 포괄하는 광범위한 분야다. 기사의 주요 부분의 구조는 기사의 종류에 따라 달라질 것이다. 여기 몇 가지 다른 종류의 컴퓨터 과학 기사를 구성하기 위한 몇 가지 일반적인 지침이 있다. 가능한 경우, 이러한 지침은 "좋은" 기사의 한두 가지 예를 포함한다. 즉, 기사는 특정 등급의 기사에서 우리가 지향하는 스타일을 보여준다. 이러한 조항들은 엄격한 규칙이 아니라 지침이라는 것을 항상 명심하라: 어떤 조항들은 이 구조에서 벗어나야 할 필요가 있을 것이다; 어떤 조항들은 분류하기가 어려울 것이다; 어떤 것들은 이 분류들에 전혀 들어맞지 않을 것이다. 이러한 지침을 적용할 때 상식을 사용하십시오.

알고리즘 및 데이터 구조

알고리즘에 관한 기사는 일반적으로 다음과 같이 구성되어야 한다.

  1. 알고리즘 설명(가성코드 포함)
  2. 알고리즘의 시간과 공간 복잡성에 대한 공식적인 논의
  3. 구현 및 성능 문제에 대한 논의

좋은 예가 퀵소트 기사다.

데이터 구조에 관한 기사는 다음과 같이 구성되어야 한다.

  1. 구조물에 대한 설명 및 구조물에 대해 수행할 수 있는 모든 작업
  2. 해당 구조물의 적용 개요
  3. 구현 및 성능 문제에 대한 논의

고전적 문제

고전적인 문제를 설명하는 기사는 일반적으로 다음과 같이 구성되어야 한다.

  1. 문제에 대한 진술.
  2. 문제의 관련성에 대한 논의.
  3. 주목할 만한 경우, 문제의 역사에 대한 논의.
  4. 문제에 대한 해결 방법이 있는 경우 설명.

그 예로는 식사 철학자들의 문제가 있다.

디자인 패턴

고전적인 GoF 형식은 디자인 패턴을 설명하는 기사의 구조에 대한 좋은 지침이다.

연구 분야

컴퓨터 과학 내의 연구 분야를 설명하는 기사에는 다음이 포함되어야 한다.

  1. 현장 역사의 간략한 개요
  2. 이 분야를 중심으로 한 주요 개념에 대한 기본 소개
  3. 현장에서 도출된 중요 원칙, 정리 또는 결과에 대한 설명
  4. 다른 연구 분야(CS 내부 및 외부)와의 관계에 대한 논의
  5. 해당 분야의 특정 측면을 보다 상세히 기술하는 기사에 대한 몇 가지 조언

형식주의

형식주의를 설명하는 기사에는 다음이 포함되어야 한다.

  1. 형식주의 역사의 간략한 개요(원제, 주요 발전 등)
  2. 관련된 기본 개념에 대한 비공식적인 소개(일부 간단한 예시 포함)
  3. 형식적 정의
  4. 중요한 애플리케이션 또는 구현에 대한 논의
  5. 형식주의를 지원하는 주요 도구에 대한 설명
  6. 관련 또는 파생 형식에 대한 간략한 개요

좋은 예는 람다-미적분학이다.

프로그래밍 구성

프로그래밍 구조를 설명하는 기사에는 일반적으로 다음이 포함되어야 한다.

  1. 구성 요소가 무엇이고, 구성 요소가 어떻게 사용되는지에 대한 간략한 개요(아마도 비공식 운영 의미론 포함)
  2. 구성에 대한 대체 이름 목록
  3. 사용 중인 구조를 보여주는 유사 코드 또는 소 코드 샘플
  4. 구성 요소와 다른 구성 요소 사이의 동등성에 대한 설명
  5. 구성의 의미론적 변화에 대한 논의
  6. 시공의 사용에 대한 불이익에 대한 논의

그 예로는 지속, 폐쇄(컴퓨터 과학), 예외 처리 등이 있다.

프로그래밍 언어

프로그래밍 언어를 설명하는 기사에는 일반적으로 적어도 다음이 포함되어야 한다.

  1. 그 언어의 역사에 대한 간략한 개요
  2. 언어 기능 개요
    • 언어가 지원하는 프로그래밍 패러다임과 이를 얼마나 잘 지원하는지
    • 유형 확인 스타일, 계약 또는 기타 사양 기법에 의한 설계 지원
    • 메모리 관리 스타일
  3. 언어 구문에 대한 기본 소개(일부 코드 샘플 포함)
  4. 언어의 공식 의미론 개요(있는 경우)
  5. 사용 가능한 구현 및 지원되는 플랫폼 목록

좋은 예가 파이썬 프로그래밍 언어 기사다.

이론과 추측

이론이나 추측을 기술하는 기사에는 일반적으로 적어도 다음이 포함되어야 한다.

  1. 정리나 추측에 대한 간략한 비공식적 설명.
  2. 정리나 추측에 대한 형식적인 진술.
  3. 정리나 추측의 역사에 대한 논의.
  4. 정리나 추측의 영향, 결과 또는 함의에 대한 논의.

많은 컴퓨터 과학의 이론과 추측이 종종 대중 문학에서 비공식적으로 언급되기 때문에, 정리나 추측에 대한 일반적인 오해나 오해에 대한 약간의 토론을 제공하는 것 또한 유익할 수 있다.

좋은 예로는 중단 문제와 처치-튜링 논문이 있다.

도구들

도구 종류를 설명하는 글은 일반적으로 다음을 포함해야 한다.

  1. 툴의 용도에 대한 간략한 개요
  2. 도구 클래스 발전의 간략한 역사
  3. 도구 클래스의 주요 하위 클래스에 대한 논의
  4. 주요 기본 알고리즘 또는 구현 기술에 대한 간략한 설명

예를 들면 컴파일러, 텍스트 편집기, 정리 프로베일러 등이 있다.

결론 사항

관련 주제와 연결되는 참고 코너나 현재 기사의 내용을 보다 잘 파악할 수 있는 페이지가 있으면 좋다.

마지막으로, 잘 쓰여지고 완성된 기사에는 참고문헌 섹션이 있어야 한다. 이 주제는 아래에서 자세히 논의될 것이다.

스타일 가이드라인

  • 문법: 수학은 중요한 이론의 증거를 언제 어떻게 포함시킬 것인가 뿐만 아니라 더 많은 이론적인 주제를 토론하는 방법에 대한 좋은 조언을 가지고 있다. 또한 방정식, 논리 표현식 및 기타 수학 표기법을 타이핑하는 방법에 대한 지침은 Manual of Style: Mathematics를 참조하십시오.
  • Manual of Style: Date and number: non-base-10 표기법은 형식(예: 이진 또는 16진수 숫자 및 메모리 주소)에 대한 조언을 제공한다.

코드 샘플

바로 가기
참고 항목: 도움말:Wikitext § 형식

가장 일반적인 이유는 특정 언어의 "모양"을 보여주고, 언어별 구성이나 특징의 예를 제공하고, 가성 코드로 쉽게 표현되지 않는 알고리즘의 예를 제공하기 위함이지만, 실제 출처의 샘플은 다양한 이유로 기사에 포함된다. 샘플 코드를 포함시키는 데 본질적으로 잘못된 것은 없지만, 과도한 양의 샘플 코드는 기사 자체의 내용을 손상시킬 수 있다; 백과사전적 내용에 대한 근본적인 이해에 크게 기여하지 않는 한 샘플 코드의 쓰기를 피한다.

위키피디아는 소스 코드 리포지토리가 아니다. 백과사전 내용과 관련이 없는 코드는 위키백과에서 옮겨야 한다. WikiBooks는 기존 GFDL 호환 코드에 적합한 Wikimedia 프로젝트로서, 특히 Wikibooks:알고리즘 구현. 외부 LiteratePrograms 및 Rosetta Code Wiki는 구현 방법 설명과 함께 새로운 샘플 구현을 배치하기에 적절한 장소다. Important note: existing implementations on Wikipedia cannot be transferred to the LiteratePrograms wiki because Wikipedia content is licensed under the GFDL and/or CC-BY-SA, while LiteratePrograms uses the more liberal MIT/X11 license; relicensing existing code from GFDL/CC-BY-SA to MIT/X11 would require the permission of all copyright holders

코드 샘플에 대한 몇 가지 일반적인 지침:

  • 알고리즘의 샘플 구현은 괜찮지만, 모든 알고리즘 기사에는 가능한 경우 핵심 알고리즘에 대한 유사 코드 설명이 포함되어야 하며, 이를 통해 알고리즘이 어떻게 작동하는지 누구나 이해할 수 있어야 한다. 유사 코드에 대한 지침은 아래를 참조하십시오.
  • 표본은 비록 그 언어가 잘 알려져 있다고 믿더라도, 그 언어가 비교적 생소한 독자에게 알고리즘을 명확하게 보여주는 언어를 사용해야 한다. 언어 중립을 유지하려면 인기가 아닌 명확성에 따라 언어를 선택하십시오. 파이썬이나 루비처럼 가독성을 강조하는 언어가 좋은 선택이다. 난해하거나 언어별 작업을 피하십시오.
  • 소스 코드 구현은 GFDL 및 CC-BY-SA 라이센스(GPL과 호환되지 않음)와 호환되어야 한다.
  • 복수의 소스 코드 구현은 코드의 특정 측면을 대조하고 그 대조가 기사의 백과사전적 내용에 중요한 경우가 아니라면 적절하지 않다. 가능하면 대체 구현을 원본과 동일한 언어로 제공하여 차이를 강조한다.
  • 모든 코드 샘플은 다음 방법 중 하나를 사용하여 표시해야 한다.
    • 짧은 인라인 코드 샘플 주변: <code> 태그
    • 암호 블록을 둘러싸고 <pre> 또는 <syntaxhighlight lang="x"> 태그
    • 코드 블록의 각 행을 하나 이상의 공백으로 들여쓰기(위 방법과는 달리 샘플에서 기울임꼴, 굵게 등과 같은 기본 텍스트 형식을 사용할 수 있음)

    이는 공간을 보존하기 위해 이들을 단일 공간 서체로 타이핑하고, 스크린 리더와 사용자들에게 맞춤형 CSS를 통해 추가 정보를 제공한다. 공백이 구문적으로 중요한 언어인 경우, 특히 이 작업을 수행하는 것은 중요하다. 특히 우리는 사람들이 샘플 코드를 복사하여 텍스트 편집기나 IDE에 붙여넣을 수 있기를 바란다. 예를 들어, 

    int main(주문) { printf("hello, world\n"; return 0; }
  • 구문 강조 표시는 다음 대신 MediaWiki 태그를 사용하여 얻을 수 있다. <pre>여기서 x는 사용되는 언어다. 자세한 내용은 확장자:구문지원되는 언어에 대한 강조 표시 다음은 구문 강조 Java 코드(예: 
    계급 안녕 세계 {     공공 정태의 공허하게 하다 본래의(끈[] 아그) {         시스템.밖으로.인쇄하다("헬로 월드!"); // "Hello World!" 인쇄     } }
  • 코드 목록은 줄에 싸여 있지 않고, 많은 사람들이 공간 제약이 있는 환경에서 위키피디아를 읽으므로, 코드 목록의 최대 줄 길이는 60자인지 확인하십시오. 필요한 경우 수동 워드 랩을 도포하십시오.

알고리즘

바로 가기

위키피디아에 알고리즘을 제시하기 위해 보편적으로 받아들여지는 표준은 없다. 표준화된 유사문서에 대한 과거 시도는 User:Dcoetzee/Wikicode는 "허락을 얻을 것 같지 않으므로 그러한 제안이 다시 진전되지 않도록 조언한다"고 말했다. 이 위키프로젝트 내에서, 가능한 경우 알고리즘을 가성으로 제시해야 한다는 의견이 일반적으로 일치해 왔다. 유사코드의 사용은 완전히 언어 불가지론적이며, 일반적으로 프로그래밍 언어와 관련하여 NPOV가 더 많다. 또한 Phyocode는 구현 세부사항의 수준에 관해서 훨씬 더 많은 유연성을 제공하므로, 구현 방법의 세부사항보다는 알고리즘과 핵심 아이디어에 초점을 맞추기 위해 아무리 높은 수준에서 알고리즘을 제시할 수 있다. 마지막으로, 적절히 높은 수준의 가성 코드는 특히 비 프로그래머에게 가장 접근하기 쉬운 알고리즘의 표시를 제공한다.

예

알고리즘 포드 풀커슨 입력: 그래프 G(흐름 용량 c, 소스 노드 s, 싱크 노드 t 출력): 유동 f과 같이 f은 최대 노드 너 가 노드 v에서 s몸 상태를(참고가 f(u,v)로 떨어진 것은 흐름, 그리고 노드 너 가 노드 v에서 GE의 각 가장자리(u, v)에 c(u,v)은 흐름 용량)f(u, v)←니 0f(v마)← 0이 존재하는 경로 p에서에 몸 상태로 네트워크 Gf를 하게 하십시요 cf 흐름 용량의 잔류 네트워크 Gf. cf(p)←분{cf(u, v)(u, v) 각 에지(u, v)에 대한 p} in p do f(u, v) ← f(u, v) + cf(p) f(v, u) ← -f(u, v) return f

유사문자 작성을 위한 일반 지침

  • 이 페이지를 먼저 읽지 않고도 알고리즘을 이해할 수 있는지 확인하십시오.
  • 모든 할당, 비교 및 기타 수학 연산자는 가능한 경우 적절한 수학 기호를 사용하여 렌더링해야 한다.
연산자 결과 독립체 예
과제 ← 또는 := &larr;, := c ← 2πr, c := 2πr
비교 =, ≠, <, >, ≤, ≥ =, &ne;, <, >, &le;, &ge;
산술 +, −, ×, /, mod +, &lt;, ×, /, mod
바닥/천장 ⌊, ⌋, ⌈, ⌉ &lfloor, &lceil, &rceil; a ← ⌊b⌋ + ⌈c⌉
논리적인 그리고, 또는 ''and', ''or''' a ≥ b and a ≤ c
합계 ∑ ∏ &sum; &prod; h ← ∑a∈A 1/a
  • 알고리즘 개요에 초점을 맞추고 가능한 경우 알고리즘에 대한 논의와 설명을 가성 코드 밖에서 계속하십시오.
저준위성 유사음
  • 모든 제어 구조 키워드는 굵게 표시되어야 하며, 코멘트는 기울임꼴로 표시되어야 한다(코멘트를 표시하는 다른 방법 이외에).
  • 대부분의 구현 세부사항을 방지하기 위해 알고리즘 설명을 충분히 높은 수준으로 유지하십시오.
  • 특정 언어 또는 프로그래밍 패러다임에 관용적인 구조나 기법을 사용하지 않도록 하십시오.
  • 관용적 구조나 기법이 불가피할 경우 아래에 설명된 스타일에 맞춰 일반적인 고급 방식으로 표현해 보십시오.
  • 선호하는 조건 구조는
만약 조건이라면 다른 코드 경로, 조건이라면 다른 코드 경로는 다음과 같은 경우 종료된다.
  • 선호하는 루프 구성 요소는
조건에서는 코드 차단을 반복하십시오.
, 그리고
loop_control의 경우 코드 블록 반복
여기서 는 등 루프에 대한 제어에 적합한 조항이다.
  • 선호하는 함수 정의 구조는
function_name은(는) 코드 블록 반환 변수 엔드 기능이다.
여기서 는 함수 이름과 인수의 합리적인 형식이다. 또는 입력과 출력을 기능 블록 내에 지정할 수 있다.
function_name 입력: 입력 출력 설명: 출력 코드 블록 리턴 변수 엔드 기능 설명
  • 코드 블록은 들여써야 한다. 충분히 명확한 경우, 닫는 키워드(끝, 반복 등)를 생략할 수 있다.

알고리즘 페이지와 버킷 정렬, 위상학적 정렬, 폴라드의 rho 알고리즘에 이러한 지침을 대략적으로 준수하는 유사 코드의 예가 제공된다.

고수준 유사음파
입력 입력 인수 설명
출력 출력 설명
  1. (알고리즘의 단계 표시)
  2. (알고리즘의 다음 단계)
    1. (바깥쪽)
  3. (등)
마크업 사용:
 :'Inputs'''''입력 인수 설명' :'출력''''' 출력 설명') :#' :#'(알고리즘의 한 단계 설명) :#' (알고리즘의 다음 단계) :#' (하위 스텝)' :#' (etc.)'
  • 단계 설명은 높은 수준이어야 하며, 단순히 영어 문장일 수도 있다.
  • 가지 조건 또는 루프 구조로 인해 알고리즘의 하위 단계는 들여쓰여지고 번호가 매겨져야 한다.
  • 반환 값이 있는 알고리즘 종료는 키워드 반환을 사용하여 표시되어야 한다.

이 형식의 알고리즘의 예로는 Buchberger의 알고리즘인 Pohlig–이 있다.Hellman 알고리즘, Itoh-Tsujii 반전 알고리즘, Baby-step 거대 스텝, Pollard의 p - 1 알고리즘.

문헌 및 참고 자료 포함

기사가 문헌에 대한 참조와 포인터의 목록을 잘 갖추는 것은 꽤 중요하다. 이에 대한 몇 가지 이유는 다음과 같다.

  • 위키백과 기사는 교과서(Wikibooks의 목적)의 대체물이 될 수 없다. 또한, 종종 더 많은 세부사항을 알고 싶을 수도 있다.
  • 어떤 개념은 문맥이나 작성자에 따라 다르게 정의된다. 기사에는 주어진 용도를 뒷받침하는 몇 가지 참고문헌이 포함되어야 한다.
  • 중요한 알고리즘, 정리 또는 정의는 역사 논문을 추가 정보로 인용해야 한다(찾아보기 위해 반드시 그렇지는 않다).
  • 오늘날 많은 연구 논문이나 심지어 책도 온라인에서 자유롭게 구할 수 있고 따라서 사실상 위키피디아에서 단 한 번의 클릭만으로 이용할 수 있다. 새로 온 사람들은 어떤 주제에 대한 논의와 즉각적인 연관성을 갖는 것으로 큰 이익을 볼 것이다.
  • 추가 읽기를 제공하면 다른 편집자들이 특정 출처의 품질을 논할 뿐만 아니라 주어진 정보를 확인하고 확장할 수 있다.

위키백과 MOS:VAR은 특정 참조와 인용 스타일을 강제하지는 않지만, 한 가지 권장사항은 정확하고 신속하게 제작할 수 있는 인용 스타일을 선택할 수 있는 것이다. 예를 들어 2018년 6월 현재 구글 스콜라(Google Scholar)는 MLA, APA, 시카고, 하버드, 밴쿠버 인용 스타일로 참조를 자동 생성할 수 있다.

위키백과:cite 출처 기사는 이에 대한 더 많은 정보와 인용된 문헌이 어떻게 보여야 하는지에 대한 몇 가지 예시를 담고 있다.

참고 항목

추가 읽기

  • 저스틴 조벨(2004년). 컴퓨터 과학을 위한 쓰기 (제2판) 스프링거. ISBN1-85233-802-4.