Skip to content

Latest commit

 

History

History
177 lines (134 loc) · 9.35 KB

CONTRIBUTING.md

File metadata and controls

177 lines (134 loc) · 9.35 KB

개발자 가이드

이슈 작성

  • 검색을 통해 답을 찾을 수 있는지 먼저 확인해 주십시오.
  • 관련된 이슈가 이미 있는지 검색하고, 같은 내용이라면 댓글로 덧붙여 주십시오. 오래된 이슈라도 메일로 알림이 전달되므로 묻힐 염려가 없습니다.
  • 무관한 이슈에 댓글을 달지 말아 주십시오. 엉뚱한 사람에게 메일 알림이 전달됩니다.
  • 2가지 이상 서로 다른 문제가 있는 경우, 각각 이슈를 등록해 주십시오.
  • 보안 취약점은 공개적으로 언급하지 말고 메인테이너들의 이메일로 알려 주시기 바랍니다.
  • 버그 신고 전 자신의 개발 환경이 아래의 조건들을 충족하는지 확인해 주십시오.
    • 브라우저가 최소 지원 버전을 만족하는지 확인해 주십시오.
    • 컴파일 및 실행용 서버 소프트웨어를 설치하실 경우 Python, Django, Docker 및 각종 서버 환경이 정상적으로 설정되었는지 확인해 주십시오.
  • 버그 신고에는 아래의 내용을 반드시 포함해 주십시오.
    • 실행 환경
      • 브라우저 확장 프로그램 버전 (예: 1.0.0)
      • 브라우저 종류 및 버전 (예: IE 11)
    • 에러가 발생하는 경우 에러 메시지 전체
      • 화면상에 에러가 표시되거나 디자인이 깨져 보이는 경우, 해당 스크린샷
      • 브라우저의 개발자도구(F12)에 에러가 표시되는 경우, 콘솔 및 네트워크 탭의 스크린샷
    • 증상을 확인해 볼 수 있는 웹사이트 주소
      • 내부망이나 로컬 개발환경 등 외부인의 접속이 원천적으로 불가능한 경우가 아니라면 반드시 주소를 남겨 주시기 바랍니다.
      • 공개적인 개발을 추구하는 오픈소스 소프트웨어의 특성상, 이슈 해결에 필요한 정보를 공개하지 않는 경우 처리가 지연되는 등의 문제가 발생할 수 있습니다.

풀 리퀘스트(PR) 작성

  • 자신의 저장소에서 별도의 브랜치를 만들어 작업하신 후, develop 브랜치로 풀 리퀘스트를 넣어주시면 됩니다.
    • 브랜치 이름은 do/something 형태를 따릅니다. 이때 "do" 부분은 적절한 동사, "something" 부분은 PR의 내용과 연관된 함축적인 문구입니다. 직관적인 "do" 동사를 선정하기 어렵다면 단순히 pr/something 형태를 사용하시기 바랍니다.
    • 예: 아이콘 관련 버그를 수정하는 경우 자신의 저장소에서 fix/icon 브랜치를 만들어 작업하십시오. 네트워크 기능을 개선했다면 pr/network 브랜치를 만들어 작업하십시오. 작성 후에 수정할 것이 있으면 이 브랜치에서 계속 작업하고 커밋하시면 됩니다. PR 페이지에 자동으로 반영됩니다.
    • 브랜치 이름 규칙을 따르지 않은 PR의 경우 안정성의 문제로 거부될 수 있습니다.
  • 개발 진행 및 안정화에 따라 브랜치별 운영 정책이 변경될 수 있으니 유의하십시오.
  • 아래의 코딩 규칙을 지키려고 노력해 주시기 바랍니다.
  • 코딩 규칙에 맞지 않는 소스를 발견하더라도 PR의 주제와 관계없는 부분은 함부로 고치지 마십시오! 코딩 규칙에 맞도록 소스를 수정하는 작업은 모두 별도의 PR로 처리하여야 합니다.
  • 단, PR을 검토하는 개발자들은 괄호의 위치와 같은 사소한 문제를 지적하느라고 실제 기능에 관심을 주지 못하는 오류를 범하지 않도록 노력해야 합니다.
  • PR의 제목은 커밋 메시지에 적용되는 규칙을 참고하되, 가능하면 한글로 작성해 주십시오.
  • 유닛 테스트를 통과하지 못하거나, 통과하기 위해 테스트를 삭제할 경우 PR이 거부될 수 있습니다. 단, 테스트 자체에 문제가 있거나 테스트 내용을 변경해야 한다고 생각되는 경우 개발팀과 의논해 주십시오.

저작권 및 라이선스

  • 모든 소스 코드의 저작권은 해당 작성자가 가집니다.
  • 모든 소스 코드에는 LGPLv3 라이선스가 적용됩니다.
    • Codify 개발팀을 비롯한 전 세계 누구라도 어떤 목적으로든지 자유롭게 사용, 수정, 재배포할 수 있습니다.
    • 타인에게 저작권이 있는 코드를 가져온 경우, 원본의 라이선스를 LGPLv3로 전환할 수 있어야 합니다.
    • 한 번 적용한 라이선스는 철회할 수 없습니다.
  • 풀 리퀘스트를 작성하실 경우 위의 두 가지에 동의하시는 것으로 간주합니다.

코딩 규칙

일반

HTML, CSS, JavaScript, XML, Python 등 모든 텍스트 파일의 문자셋은 BOM이 없는 UTF-8입니다.

줄바꿈 문자는 유닉스 방식(LF)을 따릅니다.

들여쓰기는 4칸의 공백으로 합니다. 단, 공백 대신 탭을 사용하는 파일에서는 일관성 유지를 위해 1개의 탭을 사용할 수 있습니다.

들여 쓴 줄들 사이의 빈 줄은 들여 쓰지 않습니다. (에디터에서 후행 공백을 제거하도록 설정하십시오.)

공백 및 줄바꿈 규칙(JavaScript)

함수 선언과 if, for, while 등의 중괄호는 같은 줄에 씁니다.

while (flag1) {    // RIGHT
    if (flag2)
    {              // WRONG
        
    }
}

조건문이나 순환문 내에 하나의 명령만 있는 경우에도 반드시 중괄호를 사용합니다. 그래야 나중에 명령이 추가될 경우 수정하기 편리합니다.

if (flag1) return false;    // WRONG
if (flag2) {                // RIGHT
    return true;
}

자바스크립트에서는 거의 모든 함수가 클로져이며, 잘못 줄바꿈 하면 세미콜론이 삽입될 수 있으므로 클로져도 중괄호를 같은 줄에 씁니다.

$("#foo").on("click", function() {    // OK
    if ($(this).val() === "bar") {    // OK
        $(this).val("baz");
    }
});

함수 호출 시 함수명과 괄호 사이, 괄호와 인자 사이에 공백을 두지 않습니다. 인자를 구분하는 쉼표는 뒤쪽에만 한 칸의 공백을 둡니다.

function foobar(baz, param)        // RIGHT
function foobar ( baz , param )    // WRONG

if, for, while 등의 키워드 뒤에는 한 칸의 공백을 두며, ==, !=, > 등의 연산자는 앞뒤에 한 칸씩 공백을 둡니다.

if (foo === bar)    // RIGHT
if(foo==bar){       // WRONG

자바스크립트와 JSON에서는 여러 줄에 걸쳐 배열을 선언할 경우, 마지막 쉼표를 반드시 삭제해야 합니다. 쉼표를 남겨두면 일부 브라우저에서 오류가 발생할 수 있기 때문입니다.

var animals = [
    'bear',
    'cat',
    'dog'    // NO COMMA
];

공백 및 줄바꿈 규칙(Python)

여러 줄에 걸쳐 배열을 선언할 경우, 마지막 구성요소 뒤에 쉼표를 남깁니다. 그래야 나중에 구성요소를 추가할 때 편리합니다.

animals = [
    'bear',
    'cat',
    'dog',    // COMMA
];

주석

주석은 관련 코드 윗줄에 써야 합니다. 조건문이나 루프도 마찬가지입니다.

// If flag is true, do something.
if (flag)
{
    // Note: this will do X, Y, and Z.
    doSomething();
}
// Otherwise, do something else.
else
{
    // TODO: Refactor this later.
    doSomethingElse();
}

모든 클래스와 함수에는 주석을 붙여야 합니다. 주석 작성에 어려움이 있는 경우, 다른 클래스와 함수의 주석을 참고하십시오.

불가피한 경우를 제외하면 주석은 영문으로 쓰는 것을 원칙으로 하며, 대문자로 시작하는 완전한 문장으로 이루어져야 합니다.

커밋 메시지

커밋 메시지는 가능하면 영문으로 작성하며, 동사원형으로 시작하는 현재형, 명령형 문장 사용을 원칙으로 합니다.

Delete unnecessary condition     // RIGHT
Fix #1234                        // RIGHT
Deletes unnecessary condition    // WRONG (불필요한 동사 변화)
Fixed #1234                      // WRONG (불필요한 과거형)

이 규칙에 맞추어 영문으로 커밋 메시지를 작성하기 어려운 경우, 한글로 작성해도 무방합니다. 한글 커밋 메시지는 어디서 무엇을 어떻게 했는지 간결하고 명확하고 격식 있게 표현하며, 가능하면 현재형 동사로 마치도록 합니다.

크롬 최신 버전에서 스크립트 오류 해결   // RIGHT
Foo 클래스에 bar() 메소드 추가       // RIGHT
서버 통신 에러 나는 거 고쳤어요. 헣~^^ // WRONG (격식 없는 표현)
함수 개선                          // WRONG (두리뭉실한 표현)

기타

지원하는 모든 브라우저의 기본 설정 하에서 Strict mode를 사용할 때 어떠한 에러도 발생하지 않도록 하는 것을 목표로 하지만, 경고를 일으키는 문제도 가능하면 만들어내지 않도록 합니다.

문자열과 문자열, 정수와 정수를 비교할 때는 가능하면 == 대신 ===을 사용합니다.

여기에서 규정하지 않은 내용은 JavaScript의 경우 Google JavaScript Style Guide를, Python의 경우 PEP 8 -- Style Guide for Python Code를 따릅니다.