머리말:
프로그래밍 언어의 코딩 스타일은 특히 팀워크에서 장기 유지 보수 소프트웨어에 매우 중요합니다. 팀이 통합적이고 표준화 된 코딩 스타일을 사용하는 경우 팀의 협업 수준과 작업 효율성을 향상시킬 수 있습니다. 프로그래밍 스타일 가이드의 핵심에는 높은 수준의 코드를 작성하는 방법을 결정하는 기본 서식 규칙이 있습니다. 이 안내서는 "Java Language Coding Spections"및 Crockford의 JavaScript 프로그래밍 사양과 Nicbolas의 개인적인 경험 및 선호도를 기반으로하는 "Striting Maintailable JavaScript"에서 나왔습니다. 이 기사를 작성하는 목적은 인상을 심화시키고 더 많은 사람들이 JS 코딩 스타일을 이해하고 코딩 품질을 향상시키는 것입니다. 자세한 내용은 "관리 가능한 JavaScript 작성"을 읽으십시오.
1. 계약
각 행의 레벨은 4 개의 공간으로 구성되며 탭을 사용한 압입을 피합니다.
// 좋은 쓰기 방법 if (true) {dosomething ();}2. 행의 길이
각 라인의 길이는 80자를 초과해서는 안됩니다. 라인이 80 자를 초과하면 연산자 후에 파손되어야합니다. 다음 줄은 두 가지 수준의 압입 (8 자)을 추가해야합니다.
// 양호한 쓰기 방법 (Argument1, Argument2, Aegment3, argument4, argument5); // 나쁜 쓰기 방법 : 들여 쓰기 dosomething (argument1, argument2, aegment3, argument4, argument5);
3. 원래 가치
문자열은 항상 이중 따옴표를 사용하고 한 줄을 유지하여 슬래시를 사용하여 문자열에서 한 줄을 시작해야합니다.
숫자는 소수 정수를 사용해야하며 과학적 알고리즘은 정수, 16 진수 또는 소수점 부동 소수점을 나타냅니다. 소수점 전후에 적어도 하나의 숫자를 유지해야합니다. Octal 직접 수량을 사용하지 마십시오.
다음 경우를 제외하고 특별 값 Null은 피해야합니다.
• 변수를 초기화하는 데 사용되는데, 이는 객체에 값을 할당 할 수 있습니다.
• 객체가 아니거나 아닐 수있는 초기 변수와 비교하는 데 사용됩니다.
• 함수의 매개 변수가 객체가 될 것으로 예상되면 매개 변수로 전달됩니다.
• 함수의 반환 값이 객체가 될 것으로 예상되면 반환 값으로 전달됩니다.
정의되지 않은 특수 값을 사용하지 마십시오. 변수가 정의되어 있는지 확인하려면 연산자를 사용해야합니다.
4. 운영자 간격
표현을 깔끔하게 유지하려면 이진 예산 전후에 공간을 사용해야합니다. 운영자에는 할당 연산자 및 논리 연산자가 포함됩니다.
// (var i = 0; i <count; i ++) {process (i);} // 잘못 쓰는 글쓰기 : (var i = 0; i <count; i ++) {process (i);}에 대한 분실 된 공간5. 브래킷 간격
브래킷을 사용할 때는 왼쪽 브래킷 직후와 닫기 직전에 공간이 없어야합니다.
// (var i = 0; i <count; i ++) {process (i);} // 잘못 쓰기 : 매개 변수의 양쪽에 추가 공백이 있습니다 (var i = 0; i <count; i ++) {process (i);}6. 직접 객체 측정
객체의 직접 수량은 다음 형식을 가져야합니다.
• 시작 왼쪽 버팀대는 표현과 같은 선에 보관해야합니다.
• 각 속성의 이름 값은 들여 쓰기를 유지해야하며, 첫 번째 속성은 왼쪽 곱슬 브레이스 후에 새 줄이어야합니다.
• 각 속성의 이름 값은 따옴표없이 사용하고 콜론 (공간 이전)과 값이 뒤 따릅니다.
• 속성 값이 함수 유형 인 경우 함수 본문은 속성 이름으로 새 줄을 시작하고 빈 줄을 보관해야합니다.
• 코드의 가독성을 향상시키기 위해 관련 특성 세트 전후에 빈 줄을 삽입 할 수 있습니다.
• 결말 오른쪽 버팀대는 한 줄만 독점적으로 차지해야합니다.
// 양호한 쓰기 방법 var 객체 = {key1 : value1, key2 : value2, func : function () {// dosomething}, key3 : value3}; // 잘못 쓰기 방법 : 부적절한 압입 var 객체 = {value1, key2 : value2}; // bad Writing Method : body var var var var var var var var var var var}, value1 : value1, funt2, funt2 : el. // dosomething}, key3 : value3};객체 문자가 함수 매개 변수로 사용되는 경우 값이 변수 인 경우 시작 버팀대는 함수 이름과 동일한 줄에 있어야합니다. 이전에 나열된 다른 모든 규칙도 적용됩니다.
// 양호한 쓰기 방법 DOSOMETHENT ({key1 : value1, key2 : value2}); // 잘못 쓰는 방법 : 모든 코드 dosomething ({key1 : value1, key2 : value2});7. 의견
간결하고 명확한 의견을 사용하면 다른 사람들이 코드를 이해하는 데 도움이 될 수 있습니다. 주석은 다음 상황에서 사용해야합니다.
• 코드가 모호합니다.
• 오류로 오인 될 수있는 코드.
• 필요하지만 명백하지 않은 브라우저 별 코드.
• 객체, 방법 또는 속성의 경우 문서를 생성해야합니다 (적절한 문서 주석 사용).
한 줄의 주석
단일 라인 주석을 사용하여 한 줄의 코드 또는 관련 코드 세트를 설명해야합니다. 단일 라인 주석을 사용하는 세 가지 방법이있을 수 있습니다.
• 다음 코드 라인을 설명하는 독점 의견.
• 코드 줄 끝에서 코드를 설명하기 위해 코드를 설명합니다.
• 여러 줄의 코드 블록을 댓글을 달았습니다.
// (조건) {// 코드가 여기에 실행되면 모든 보안 검사가 통과되었음을 의미합니다.} // 잘못된 글쓰기 : 댓글 이전에 빈 줄이 없음 (조건) {// 코드가 실행되면 모든 보안 검사가 통과되었음을 의미합니다. 통과;} // 나쁜 글쓰기 : 다중 라인 주석을 사용해야합니다. //이 코드는 ** 판단에 사용됩니다. // if (조건) {// 코드가 실행되면 모든 보안 검사가 통과되었음을 의미합니다. 허용된(); // ** function} // 저술 불량한 글쓰기 : 코드와 댓글 사이에 충분한 공간이 없다. // ** function} // good writing을 실행합니다. 좋은 쓰기 : 코드 블록을 댓글을 달 때 한 줄의 주석을 사용하려면 연락해야 하며이 경우에는 멀티 라인 주석을 사용해서는 안됩니다. // if (조건) {// enver (); // execute ** function //}멀티 라인 댓글
코드가 해석하기 위해 더 많은 텍스트가 필요할 때 멀티 라인 주석을 사용해야합니다. 각 다중선 주석에는 다음과 같이 최소 3 줄이 있습니다.
1. 첫 번째 줄에는 /* 댓글 시작 만 포함됩니다. 이 줄에는 다른 텍스트가 없어야합니다.
2. 다음 줄은 *로 시작하여 왼쪽 정렬 상태로 유지됩니다. 이것들은 말로 설명 할 수 있습니다.
3. 마지막 줄은 */로 시작하며 이전 줄과 정렬 된 상태로 유지됩니다. 다른 텍스트가 없어야합니다.
멀티 라인 주석의 첫 번째 줄은 코드를 설명하는 것과 동일한 수준의 압입을 유지해야합니다. 각 후속선은 동일한 수준의 압입과 공간이 부착되어야합니다 ( * 문자를 올바르게 유지하기 위해). 빈 줄은 각 다중선 코드 전에 예약해야합니다.
// 우수한 쓰기 방법, if (조건) {/** 코드가 여기에서 실행되는 경우* 모든 보안 탐지가 전달되었음을 의미합니다*/ enver ();}의견 진술
주석을 사용하여 추가 정보를 코드에 선언 할 수 있습니다. 이 진술의 형식은 단일 단어로 시작하여 즉시 결장으로 이어집니다. 사용할 수있는 진술은 다음과 같습니다.
TODO : 설명 코드는 아직 완료되지 않았습니다. 다음에하고 싶은 일이 포함되어야합니다.
해킹 : 코드 구현이 바로 가기를 가져 왔음을 보여줍니다. 해킹이 사용되는 이유를 포함해야합니다. 이것은 또한 문제에 대한 더 나은 해결책이있을 수 있음을 나타낼 수 있습니다.
XXX : 코드는 문제가 있으며 가능한 빨리 수정해야한다고 설명합니다.
FIXME : 코드가 문제가 있으며 가능한 빨리 수정해야한다고 설명하십시오. xxx에 약간 두 번째입니다.
검토 : 가능한 변경 사항에서 명령 코드를 검토해야합니다.
이 선언은 하나 이상의 주석으로 사용될 수 있으며 일반 주석 유형과 동일한 형식 규칙을 따라야합니다.
8. 이름 지정
변수와 기능은 이름을 지정할 때주의해야합니다. 이름 지정은 수치 알파벳 문자로 제한되어야하며 밑줄 (_)은 경우에 따라 사용될 수 있습니다. 이름 지정에 달러 표시 ($) 또는 백 슬래시 (/)를 사용하지 않는 것이 가장 좋습니다.
가변 이름 지정은 낙타 이름 지정 형식이어야하며 첫 번째 문자 소문자와 각 단어 대문자의 첫 글자와 함께야합니다. 변수 이름의 첫 번째 단어는 동일한 함수와의 혼란을 피하기 위해 명사 (동사가 아님) 여야합니다. 변수 이름으로 밑줄을 사용하지 마십시오.
// 좋은 쓰기 방법 var accountnumber = "test001"; // 잘못 쓰는 방법 : 대문자로 시작 var ac
함수 이름도 낙타 명명 형식이어야합니다. 함수 이름의 첫 번째 단어는 동일한 변수와의 혼란을 피하기 위해 동사 (명사가 아님) 여야합니다. 함수 이름에서 밑줄을 사용하지 않는 것이 가장 좋습니다.
// 양호한 쓰기 메소드 함수 dosomething () {// code} // 잘못된 쓰기 메소드 : 함수 dosomething () {// code} // 잘못된 쓰기 메소드 : 함수 something () {// code} // 잘못된 쓰기 메소드 : 밑줄 함수 do_something () {// code}새 연산자를 통해 새 객체를 생성하는 함수 인 생성자도 낙타 형식으로 명명되어야하며 첫 번째 문자는 대문자입니다. 새로는 객체의 인스턴스를 생성하는 작업을 나타 내기 때문에 생성자 이름은 비 복구로 시작해야합니다.
// 양호한 쓰기 방법 함수 myObject () {// code} // 불량 쓰기 메소드 : 함수 myObject () 소문자 시작시 {// code} // 잘못된 쓰기 메소드 : 밑줄 함수 my_object () {// code} // 잘못 쓰기 방법 : verb getmyObject () {// code}의 함수상수의 이름 (값이 변경되지 않은 변수)은 모든 대문자 여야하며, 다른 단어 사이의 단일 밑줄로 분리되어야합니다.
// 좋은 쓰기 방법 var thant_count = 10; // 나쁜 쓰기 방법 : 낙타 양식 var totalcount = 10; // 잘못 쓰는 방법 : 혼합 양식 var thant_count = 10;
객체의 속성은 변수의 속성과 동일합니다. 객체의 방법은 함수의 방법과 동일합니다. 속성이나 방법이 개인 인 경우 밑줄이 그 전에 추가되어야합니다.
// 양호한 쓰기 방법 var 객체 = {_count : 10,4 _getCount : function () {return this._count; }}9. 변수 및 기능 선언
변수 선언
모든 변수는 사용하기 전에 미리 정의해야합니다. 변수 정의는 라인당 var 표현식 1 변수를 사용하여 함수의 시작 부분에 배치해야합니다. 첫 번째 행을 제외하고 모든 행은 변수 이름을 수직으로 정렬 할 수 있도록 하나 이상의 레이어를 들여 보내야합니다. 가변 정의는 초기화되어야하며 할당 연산자는 일관된 압입을 유지해야합니다. 초기화 된 변수는 변수가 초기화되기 전에 이루어져야합니다.
// 양호한 쓰기 방법 var count = 10, name = "jeri", found = false, empty;
기능 선언
기능은 사용하기 전에 미리 정의해야합니다. 메소드가 아닌 함수 (즉, 객체로서 속성이 없음)는 함수로 정의 된 형식 (함수 표현 및 함수 생성자 형식이 아님)을 사용해야합니다. 함수 이름과 시작 괄호 안 사이에는 공간이 없어야합니다. 결말 괄호와 오른쪽의 곱슬 괄호 사이에 공간이 남아 있어야합니다. 오른쪽의 곱슬 괄호는 함수 키워드와 같은 줄에 남아 있어야합니다. 시작과 끝 괄호 사이에는 공간이 없어야합니다. 매개 변수 이름 사이의 쉼표 뒤에 공간이 남아 있어야합니다. 기능 본문은 첫 번째 수준에서 들여 쓰기를 유지해야합니다.
// 양호한 쓰기 방법 함수 OUT () {var count = 10, name = "jeri", found = false, empty; funner inner () {// code} // inner ()}을 호출하는 코드익명 함수는 개체에 대한 메소드 또는 다른 함수에 대한 매개 변수로 할당 될 수 있습니다. 기능 키워드와 시작 브래킷 사이에는 공간이 없어야합니다.
// 양호한 쓰기 메소드 객체 .method = function () {// code}; // 잘못된 쓰기 메소드 : 잘못된 공간 개체 .method = function () {// code};즉시 호출되는 함수는 기능 호출의 외부 층의 정원 괄호로 감겨 야합니다.
// good method var value = (function () {// function body return {message : "hi"}} ());엄격한 모드
엄격한 모드는 함수 내에서만 사용해야하며 전역으로 사용해서는 안됩니다.
// 잘못된 쓰기 방법 : 엄격한 모드 사용 "엄격한 사용"; function dosomething () {// code} // 양호한 쓰기 메소드 함수 dosomething () { "Strict 사용"; // 코드}10. 운영자
과제
변수에 값을 할당 할 때 오른쪽에 비교 문이 포함 된 표현식 인 경우 괄호 안에 래핑해야합니다.
// 좋은 쓰기 var flag = (i <count); // 나쁜 글쓰기 : 누락 된 괄호 var flag = i <count;
동일한 사인 연산자
약한 유형 변환 오류를 피하기 위해 == (엄격하게 동일) 및! == (엄격하게 동일) 및! == (엄격하게 동일하지 않습니다.
// 좋은 쓰기 var same = (a === b); // good writing var same = (a == b);
트리플 연산자
3 원 운영자는 조건부 할당 명세서에서만 사용해야하며 IF 진술을 대신하여 사용해서는 안됩니다.
// 좋은 쓰기 방법 var value = 조건? value1 : value2; // 잘못된 쓰기 방법 : 표현을 사용해야한다면 과제가 없습니까? dosomething () : dosomethingelse;
11. 진술
간단한 진술
각 줄에는 최대 하나의 진술 만 포함됩니다. 모든 간단한 진술은 세미콜론 (;)으로 끝나야합니다.
// 양호한 쓰기 메소드 수 ++; a = b; // 잘못 쓰는 방법 : 다중 표현식이 한 줄로 작성됩니다. count ++; a = b;
반환 명세서
값을 반환 할 때 리턴 명령문을 괄호 안에 랩핑해서는 안됩니다. 경우에 따라 리턴 값을 이해하기 쉽게 만들 수 없다면. 예를 들어:
return; return collection.size (); return (size> 0? size : defaultsize);
화합물 진술
복합 진술은 버팀대로 둘러싸인 진술 목록입니다.
• 동봉 된 진술은 복합 진술보다 한 수준을 더 많이 들여야합니다.
• 시작 버팀대는 복합 문장이있는 선의 끝에 있어야합니다. 종료 브레이스는 한 줄을 점유해야하며 복합 문의 시작과 동일하게 들여 쓰기를 유지해야합니다.
• 진술이 IF 또는 진술과 같은 제어 구조의 일부인 경우, 모든 진술은 단일 진술을 포함하여 교정기에 포함되어야합니다. 이 컨벤션을 통해 괄호를 추가하는 것을 잊고 버그를 일으키는 것에 대해 걱정하지 않고 진술을 더 쉽게 추가 할 수 있습니다.
• 시작 해야하는 경우와 같은 명세서의 키워드, 공간과 시작 버팀대에이어야합니다.
IF 문
if 문은 다음 형식이어야합니다.
if (조건) {statements} if (조건) {statements} else {statements} if (조건) {statements} else if (조건) {statements} else {statements}if 문장에서 곱슬 괄호를 생략 할 수는 없습니다.
// 양호한 쓰기 if (조건) {dosomething ();} // 잘못 쓰는 글쓰기 : 부적절한 공간 if (조건) {dosomething ();} // 잘못 쓰는 글쓰기 : 모든 코드가 한 줄에 있습니다. if (조건) {dosomething (); } // 잘못된 쓰기 : 모든 코드는 한 줄에 있고 (조건) dosomething ();성명서
유형 문은 다음 형식이어야합니다.
for (초기화; 조건; 업데이트) {문장} for (객체의 변수) {statements}for 문의 초기화 부분에는 변수 선언이 없어야합니다.
// 양호한 방법 var i, len; for (i = 0, len = 0; i <len; i ++) {// code} // 잘못 쓰기 : (var i = 0, len = 0; i <len; i ++) {// code} // 잘못 쓰기 : (var prop in object) {// code}for-in 문을 사용할 때는 객체의 멤버를 필터링하기 위해 이중 점검을 위해 hasownproperty ()를 사용해야합니다.
성명서
where 클래스의 진술은 다음 형식이어야합니다.
while (조건) {statement}DO 성명서
DO 클래스의 진술은 다음 형식이어야합니다.
{statements} while (조건);스위치 문
스위치 클래스의 진술은 다음 형식이어야합니다.
스위치 (표현) {case expression : 명령문 기본값 : 문장}스위치 아래의 첫 번째 사례는 들여 쓰기를 유지해야합니다. 기본값을 포함한 첫 번째 사례는 기본값을 포함하여 빈 줄을 유지해야합니다.
각 진술 세트 (기본값 제외)는 휴식, 반환, 던지기 또는 주석 줄로 건너 뛰어야합니다.
// 양호한 쓰기 메소드 스위치 (value) {case 1 :/ *는 */ case 2 : dosomething (); 부서지다; 사례 3 : 진실을 반환합니다. 기본값 : 새 오류 던지기 ( "일부 오류");}스위치 문에 기본 케이스가 포함되어 있지 않으면 주석 줄을 교체해야합니다.
// 양호한 쓰기 메소드 스위치 (value) {case 1 :/ *는 */ case 2 : dosomething (); 부서지다; 사례 3 : 진실을 반환합니다. 기본값 : // 기본값 없음}문을 시도하십시오
시도 클래스의 진술은 다음과 같이 형식화되어야합니다.
try {statements} catch (variable) {statements} try {statements} catch (variable) {statements} 마침내 {statements}12. 흰색을 떠나십시오
논리 관련 코드간에 빈 코드 줄을 추가하면 코드의 가독성이 향상 될 수 있습니다.
두 개의 빈 줄은 다음 상황에서 사용되는 것으로 제한됩니다.
• 다른 소스 코드 파일 사이.
• 클래스와 인터페이스 정의 사이.
단일 라인 빈 라인은 다음 경우에만 사용할 수 있습니다.
• 방법 사이.
• 메소드의 로컬 변수와 첫 번째 줄 문의.
• 여러 줄 또는 단일 라인 주석 전에.
•이 방법의 논리 코드 블록은 코드의 가독성을 향상시키는 데 사용됩니다.
다음 상황에서는 공간을 사용해야합니다.
• 키워드 뒤에 괄호가 이어지는 경우 공간으로 분리해야합니다.
• 매개 변수 목록에 쉼표 후에 공간이 남아 있어야합니다.
• 지점을 제외한 모든 이진 연산자의 피연산자는 공간으로 분리되어야합니다. 독백 연산자의 피연산자는 단시 마이너스 부호, 증분 (++), 감소 (-)와 같은 공백으로 분리해서는 안됩니다.
• FOR 문의 표현은 공백으로 분리되어야합니다.
13. 피해야 할 사항
• 문자열과 같은 원래 래퍼 유형을 사용하여 새 개체를 만들지 마십시오.
• eval ()를 사용하지 마십시오.
• 진술과 함께 사용하지 마십시오. 이 진술은 더 이상 엄격한 모드로 존재하지 않으며 향후 ECMAScript 표준에서도 제거 될 수도 있습니다.
마지막에 작성되었습니다
위의 가이드는 개발 과정에서 완전히 따르지 않습니다. 코딩 스타일을 개선하고 코드를 읽을 수 있고 유지 관리 할 수 있도록 일부를 그릴 수 있습니다. 코딩 스타일과 관련하여 각 팀에는 고유 한 특성이 있습니다. 팀이 일관된 한 효율적으로 개발해도 괜찮습니다. 일부 규칙은 우리가 지속적으로 순종 해야하는 것이 아닙니다. 예를 들어, 들여 쓰기 측면에서, 우리는 종종 탭 키를 더 편리하게 사용하지만 탭이 모든 환경에서 4 개의 공간을 나타내는 것을 보장 할 수는 없습니다. 계약의 일관성을 유지하려면 탭 키를 사용하는 경우 프로세스 전체에서 사용해야합니다. 그리고 우리는 또한 "" "와" ""를 사용할 필요가 없으며, 일관된 스타일을 유지하는 한, 사용할 수도 있습니다.
절대적인 규칙은 없으며 적합한 것만이 없습니다.