부호화 규칙

Coding conventions
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

코딩 규칙은 특정 프로그래밍 언어에 대한 가이드라인 세트이며, 해당 언어로 작성된 프로그램의 각 측면에 대해 프로그래밍 스타일, 프랙티스 및 방법을 권장합니다.이러한 표기법에는 일반적으로 파일 구성, 들여쓰기, 주석, 선언, 스테이트먼트, 공백, 명명 규칙, 프로그래밍 프랙티스, 프로그래밍 원리, 프로그래밍 경험 규칙, 아키텍처의 베스트 프랙티스 등이 포함됩니다.소프트웨어 구조 품질에 대한 가이드라인입니다.소프트웨어 프로그래머는 소스 코드의 가독성을 향상시키고 소프트웨어 유지보수를 용이하게 하기 위해 이러한 가이드라인을 따를 것을 강력히 권장합니다.코딩 규칙은 소프트웨어 프로젝트의 인간 유지관리자 및 동료 검토자에게만 적용됩니다.규약은 전체 팀 또는 회사가 [1]따르는 문서화된 규칙 집합으로 공식화할 수도 있고 개인의 습관적인 코딩 관행처럼 비공식적일 수도 있습니다.코딩 규칙은 컴파일러에 의해 강제되지 않습니다.

소프트웨어 유지보수

소프트웨어 유지보수 비용을 절감하는 것이 코딩 규칙을 따르는 가장 많은 이유로 꼽힙니다.Java 프로그래밍 언어의 코드 표기법을 소개하면서 Sun Microsystems는 다음과 같은 [2]근거를 제공합니다.

코드 표기법은 프로그래머에게 다음과 같은 여러 가지 이유로 중요합니다.

  • 소프트웨어 1개의 라이프 타임 코스트의 40%~80%는 [3]유지보수에 소비됩니다.
  • 원저자가 평생 유지 보수하는 소프트웨어는 거의 없습니다.
  • 코드 규약은 소프트웨어의 가독성을 향상시켜 엔지니어가 새로운 코드를 보다 빠르고 철저하게 이해할 수 있도록 합니다.
  • 소스코드를 제품으로 발송하는 경우, 작성한 다른 제품과 마찬가지로 패키징이 잘 되어 있는지 확인해야 합니다.

퀄리티

소프트웨어 피어 리뷰에는 소스 코드 판독이 자주 포함됩니다.이런 유형의 안전 점검은 주로 결함 탐지 활동입니다.정의상 코드를 리뷰하기 전에 코드 조각의 원본 작성자만 소스 파일을 읽습니다.일관된 지침을 사용하여 작성된 코드는 다른 검토자가 더 쉽게 이해하고 이해할 수 있도록 하여 결함 감지 프로세스의 효율성을 개선합니다.

원저작자라도 일관된 코드 소프트웨어를 사용하면 유지보수가 용이해집니다.왜 특정 코드의 조각이 처음 작성된 후 오랜 시간 동안 특정 코드의 특정 방식으로 작성되었는지에 대한 정확한 근거를 개인이 기억한다는 보장은 없습니다.코딩 규칙을 사용하면 도움이 됩니다.공백 공간을 일관되게 사용하면 가독성이 향상되고 소프트웨어를 이해하는 데 걸리는 시간이 단축됩니다.

부호화 기준

부호화 규약이 고품질 코드를 생성하도록 특별히 설계되어 정식 채택된 경우에는 부호화 표준이 됩니다.특정 스타일은 일반적으로 채택되는지 여부에 관계없이 자동으로 좋은 품질 코드를 생성하지 않습니다.

복잡성 경감

복잡성은 보안에 [4]역행하는 요인입니다.

복잡성 관리에는 프로젝트 개발 중에 작성된 코드의 양을 최소화하는 기본 원칙이 포함됩니다.이로 인해 불필요한 작업이 방지되어 선불 및 다운스트림 모두에서 불필요한 비용이 발생하지 않습니다.이는 단순히 코드가 적으면 어플리케이션 작성뿐만 아니라 유지보수 작업도 줄어들기 때문입니다.

복잡성은 설계 단계(프로젝트의 구조화 방식)와 개발 단계(간단한 코드를 갖는 것) 모두에서 관리됩니다.코딩을 기본적이고 단순하게 유지하면 복잡성이 최소화됩니다.대부분의 경우, 이것은 가능한 한 '물리적'으로 코딩을 유지하는 것입니다. 즉, 매우 직접적이고 추상적이지 않은 방식으로 코딩을 하는 것입니다.이를 통해 읽고 따르기 쉬운 최적의 코드를 생성할 수 있습니다.간단한 작업에 복잡한 도구를 사용하지 않음으로써 복잡성을 피할 수도 있습니다.

코드가 복잡할수록 버그가 발견되기 어렵고 숨겨진 버그가 존재할 가능성이 높아집니다.

리팩터링

리팩터링이란 소스 코드를 수정하여 읽기 쉽게 하거나 구조를 개선하는 소프트웨어 유지보수 활동을 말합니다.소프트웨어는 최초 출시 후 팀의 명시된 코딩 표준에 적합하도록 리팩터링되는 경우가 많습니다.소프트웨어의 동작을 변경하지 않는 변경은 리팩터링으로 간주할 수 있습니다.일반적인 리팩터링 활동은 변수 이름 변경, 메서드 이름 변경, 메서드 또는 전체 클래스 이동 및 큰 메서드(또는 함수)를 작은 메서드로 분할하는 것입니다.

신속한 변화를 위한 소프트웨어 개발 방법론은 정기적인(또는 지속적인) 리팩터링을 계획하여 팀 소프트웨어 개발 프로세스의 필수적인 [5]부분으로 만듭니다.

태스크 자동화

코딩 규칙을 통해 프로그래머는 실행 가능한 파일로 컴파일하는 것 이외의 목적으로 소스 코드를 처리하는 단순한 스크립트 또는 프로그램을 가질 수 있습니다.소프트웨어 크기(소스 코드 줄)를 세어 현재 프로젝트 진행 상황을 추적하거나 향후 프로젝트 견적의 기준을 설정하는 것이 일반적입니다.

일관된 코드화 표준은 측정을 더욱 일관되게 만들 수 있습니다.소스 코드 코멘트 내의 특수 태그는 문서 처리에 자주 사용됩니다.두 가지 주목할 만한 예는 javadoc과 doxygen입니다.도구는 태그 세트의 사용을 지정하지만 프로젝트 내에서의 태그 사용은 규칙에 따라 결정됩니다.

코딩 규약은 기존 소프트웨어를 처리하는 새로운 소프트웨어 작성을 단순화합니다.정적 코드 분석의 사용은 1950년대 이후 지속적으로 증가해왔다.이러한 종류의 개발 도구의 성장 중 일부는 실무자 자신의 성숙도와 정교함(및 안전과 보안에 대한 현대적 초점)이 증가했기 때문이기도 하지만 언어 자체의 특성에서도 기인합니다.

언어 요인

모든 소프트웨어 담당자는 복잡한 명령어를 다수 정리하고 관리하는 문제에 대처해야 합니다.가장 작은 소프트웨어 프로젝트를 제외한 모든 소스 코드(명령어)는 다른 파일로 분할되며 많은 디렉토리 간에 분할되는 경우가 많습니다.프로그래머가 밀접하게 관련된 함수(동작)를 같은 파일에 모으고 관련 파일을 디렉토리에 수집하는 것은 자연스러운 일이었다.소프트웨어 개발이 순수 절차적 프로그래밍(FORTRAN에서 볼 수 있는 것)에서 보다 객체 지향적 구성(C++에서 볼 수 있는 것)으로 이동함에 따라, 단일(공용) 클래스에 대한 코드를 단일 파일('파일당 하나의 클래스' 규칙)[6][7]에 작성하는 것이 관례가 되었습니다.Java는 한 단계 더 나아갔습니다. Java 컴파일러는 파일당 두 개 이상의 공용 클래스를 발견하면 오류를 반환합니다.

한 언어의 규약은 다른 언어의 요건일 수 있다.언어 표기법은 개별 소스 파일에도 영향을 미칩니다.소스 코드를 처리하는 데 사용되는 각 컴파일러(또는 인터프리터)는 고유합니다.컴파일러가 소스에 적용하는 규칙에 따라 암묵적인 표준이 생성됩니다.예를 들어, Python 코드는 Perl보다 훨씬 일관되게 들여쓰기 됩니다. 왜냐하면 공백(인디테이션)은 실제로 인터프리터에 중요하기 때문입니다.Python은 Perl이 함수를 구분하는 데 사용하는 brace 구문을 사용하지 않습니다.들여쓰기 변경은 [8][9]구분자로 사용됩니다.함수를 구분하기 위해 Perl 또는 C/C++와 유사한 중괄호 구문을 사용하는 TCL은 다음을 허용하지 않습니다.이것은 C 프로그래머에게 매우 합리적인 것으로 보입니다.

 set i = 0인 반면 {$i < 10} {는 "$i 제곱 = [expr $i*$i]" incr i }을(를) 지정합니다.

그 이유는 Tcl에서는 C나 Java와 같이 함수를 구분하기 위해서만 중괄호를 사용하지 않기 때문입니다.보다 일반적으로, 곱슬괄호는 단어를 하나의 인수로 [10][11]그룹화할 때 사용됩니다.Tcl에서 while이라는 단어는 조건과 액션의 두 가지 인수를 사용합니다.위의 예에서는 에서 두 번째 인수가 누락되어 있습니다(Tcl은 명령어 끝을 구분하기 위해 줄바꿈 문자도 사용하기 때문입니다).

일반적인 표기법

코딩 규칙에는 여러 가지가 있습니다. 다양한 예제와 설명은 코딩 스타일을 참조하십시오.일반적인 코딩 규칙에는 다음 영역이 포함될 수 있습니다.

코딩 표준에는 CERT C 코딩 표준, MISRA C, 높은 무결성 C++가 포함됩니다. 아래 목록을 참조하십시오.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs". EditorConfig.
  2. ^ "Code Conventions for the Java Programming Language : Why Have Code Conventions". Sun Microsystems, Inc. 1999-04-20.
  3. ^ Robert L. Glass: 소프트웨어 엔지니어링의 사실과 오류; Adison Wesley, 2003.
  4. ^ 톰 길리스."복잡함은 보안의 적입니다."
  5. ^ Jeffries, Ron (2001-11-08). "What is Extreme Programming? : Design Improvement". XP Magazine. Archived from the original on 2006-12-15.
  6. ^ Hoff, Todd (2007-01-09). "C++ Coding Standard : Naming Class Files".
  7. ^ FIE 부호화 표준
  8. ^ van Rossum, Guido (2006-09-19). Fred L. Drake, Jr (ed.). "Python Tutorial : First Steps Towards Programming". Python Software Foundation. Archived from the original on 2008-09-28. Retrieved 2014-08-17.
  9. ^ Raymond, Eric (2000-05-01). "Why Python?". Linux Journal.
  10. ^ Tcl Developer Xchange. "Summary of Tcl language syntax". ActiveState.
  11. ^ Staplin, George Peter (2006-07-16). "Why can I not start a new line before a brace group". 'the Tcler's Wiki'.

부호화 표준 목록

Wikibooks는 다음 주제에 관한 책을 가지고 있습니다.Ada 스타일 가이드
Wikibooks는 다음과 같은 주제에 대한 책을 가지고 있습니다: 컴퓨터 프로그래밍/코딩 스타일

언어의 부호화 규칙

프로젝트의 코딩 규칙

  1. ^ "TIOBE - C Coding Standard". tics.tiobe.com. Retrieved 2021-03-11.
  2. ^ "C++ Coding Standard". tics.tiobe.com. Retrieved 2021-03-11.
  3. ^ "C# Coding Standard". tics.tiobe.com. Retrieved 2021-03-11.
  4. ^ "TIOBE - Java Coding Standard". tics.tiobe.com. Retrieved 2021-03-11.