코드 안정성, 이식성, 그리고 가장 중요한 것은 다른 개발자가 공동으로 작성한 코드의 가독성을 높이는 소프트웨어 회사에는 다양한 코딩 표준이 적용됩니다.

주목할만한 두 가지 예는 MISRA C 와 JSF 프로젝트를 위해 개발 된 C ++ 표준입니다 .

"must", "shall", "should", "might"등의 의미를 신중하게 지정한 후 일반적으로 다음과 같은 형식입니다.

예:

규칙 50 : 부동 소수점 변수는 정확한 동등 또는 부등식에 대해 테스트되지 않아야합니다.

이론적 근거 : 부동 소수점 숫자는 반올림 및 잘림 오류의 영향을 받기 때문에 예상하더라도 정확한 동등성을 달성하지 못할 수 있습니다.

이러한 코딩 표준은 일반적으로 컴파일러의 관점에서 합법적 인 코드에 제한이 있지만 위험하거나 읽을 수 없으므로 "유해한 것으로 간주"됩니다.

이제 남용하자!

귀하는 회사의 소규모 표준화위원회의 회원으로 승인되며, 이는 회사의 모든 개발자가 사용해야하는 새로운 코딩 표준을 설계하기위한 것입니다. 다른 사람들에게 알려지지 않은, 당신은 비밀리에 사악한 조직을 고용하고 있으며 회사를 방해하는 임무를 수행합니다. 나중에 개발자를 방해 할 하나 이상의 코딩 표준 항목을 제안해야합니다. 그러나이를 즉시 명백하게하지 않도록주의해야합니다. 그렇지 않으면 표준에 적용되지 않을 위험이 있습니다.

다시 말해, 합법적으로 보이고 위원회의 다른 구성원이 받아 들일 가능성이 높은 코딩 표준에 규칙을 도입해야합니다 . 프로젝트가 시작하고 수많은 사람이 시간 코드에 투자 한 후, 당신은 또는, 전문적 사항에 의해 (예를 들어, 이러한 규칙을 남용 할 수 있어야한다 아주문자 그대로 해석) 그렇지 않으면 정상적이고 우수한 품질의 코드를 표준에 위배되는 것으로 표시합니다. 따라서이를 재 설계하기 위해 많은 노력을 기울여야하며,이 시점부터 규칙이이를 방해 할 것이지만, 현재 규칙이 꽤 오랫동안 활성화되어 있기 때문에 순수한 추진력은 이러한 역할을 계속 유지하고 중대한 갈등이있을 것입니다 서로 다른 수준의 경영진 사이에 이해 관계가 있다면, 다른 관리자는 아마도 규칙을 유지하고 (실수를 인정하는 것은 어리석은 일입니다!) 회사를 방해합니다! Mwahahahahaaa!

채점

유효한 첫 응모에서 약 2 주 후에 가장 높은 투표 응답을 얻습니다. 나는 좋은 대답에 대한 아이디어를 가지고 있지만 다른 사람이 같은 아이디어를 얻을 수 있기 때문에 며칠 후에 게시 할 것이며 나는 그들을 기쁨에서 빼앗고 싶지 않습니다. 물론 점수에 상관없이 본인의 답변은 다른 어떤 것보다 받아 들여지지 않습니다.

유권자들은 허점이 얼마나 잘 숨겨져 있는지, 개발자에게 얼마나 실망 스러울 지에 따라 답을 얻는 것이 좋습니다.

규칙 및 규정

• 위의 예와 같이 규칙을 전문적으로 작성해야합니다.
• 규칙은 진짜처럼 보일 것입니다 (따라서 "모든 변수는 적어도 하나의 밑줄, 하나의 대문자, 하나의 소문자 및 두 개의 숫자를 포함해야합니다" 와 같은 것은 허용되지 않습니다. 실제로 개발자를 방해 할 것이지만 대부분은 받아들이지 않을 것입니다 위원회) 및 그 장점이 즉시 명확하지 않으면 좋은 근거를 제시해야합니다.
• 나중에 개발자를 방해하는 규칙을 사용하거나 남용하는 방법을 찾을 수 있어야합니다. 다른 규칙에서 모호성을 남용하거나 자체적으로 무해하지만 일단 결합 된 악마 규칙 인 여러 규칙을 사용할 수 있습니다!
• 게시물 끝에 스포일러 태그로 규칙을 악용 할 수있는 방법에 대한 설명을 게시해야합니다.
• 사용 된 언어는 비의가되어서는 안됩니다. 실제 프로젝트에서 널리 사용되는 언어를 선택해야하므로 Golfscript와 같은 언어 대신 C와 유사한 구문을 사용하는 언어가 선호됩니다.

C / C ++

규칙 1 : 8 진 상수는 사용하지 않아야합니다

근거 : 8 진 상수는 혼동의 원인이 될 수 있습니다. 예를 들어, const int coefficients[] = {132, 521, 013, 102};
배열을 살펴보면 배열의 숫자 중 하나가 8 진수로 정의되어 있다는 사실을 놓칠 수 있습니다.

더 악하고 싶다면 다음을 추가하십시오.

규칙 2 : 16 진 상수는 비트 조작 컨텍스트에서만 사용해야합니다.

근거 : 상수가 숫자 값을 나타내는 경우 10 진수이면 더 읽기 쉽습니다. 16 진 상수는 숫자 값이 아니라 비트 마스크를 나타냅니다.

악용 될 수있는 방법 :

배열의 처음 10 개 요소를 추가하는 다음 간단한 프로그램을 사용하십시오. 이 코드는 표준을 준수하지 않습니다.

sum = 0;
for (i = 0; i < 10; i++) 
{
    sum += array[i];
}

즉 0, 정의에 따라 8 진 상수입니다. 규칙 1에 따라 코드 전체에서 0x00으로 작성 해야하는 것은 실망 스럽습니다. 규칙 2에 따라 훨씬 더 실망 스럽습니다.

파이썬

규칙 1 : 모든 코드는 바이트 코드 -OO를 최적화하는 플래그를 사용하여 바이트 컴파일되어야합니다 . 크기와 효율성을 위해 최적화 된 바이트 코드를 원합니다!

규칙 2 : 테스트는 프로덕션에 포함될 동일한 "아티팩트"코드에 대해 실행해야합니다. 우리의 감사관은 이것을 요구합니다.

를 사용 -OO하면 assert명령문이 제거 됩니다. 규칙 2와 결합하면 assert테스트에서 명령문 사용을 효과적으로 금지합니다 . 즐기세요!

Node.JS 프로젝트를위한 것입니다.

섹션 3-속도와 효율성이 핵심

규칙 3.1 : 파일은 최대 1kb로 유지되어야합니다. 이보다 큰 파일은 구문 분석하는 데 너무 오래 걸립니다.

규칙 3.2 : 3 단계 이상의 함수를 중첩하지 마십시오. V8 엔진은 많은 변수를 추적해야하며, 이와 같은 깊은 폐쇄는 작동을 어렵게하여 일반적인 해석 속도를 늦 춥니 다.

규칙 3.3 : 회피를 피하십시오 require().

규칙 3.3.1 : 모듈 require()d require()의 깊이는 3을 넘지 않아야 합니다. 딥 require()체인은 메모리 사용량과 속도면에서 비쌉니다.

규칙 3.3.2 : 핵심 모듈은 내부적으로 require()몇 번이든 상관없이 단일 모듈로 계산됩니다 require().

규칙 3.3.3 : 외부 모듈은 최대 2 require()초로 계산됩니다 . 우리는 코어 모듈과 동일한 수준의 여유를 가질 수 없지만 모듈 작성자가 효율적인 코드를 작성한다고 가정 할 수 있습니다.

규칙 3.4 : 모든 비용으로 동기 호출을 피하십시오. 시간이 오래 걸리고 전체 이벤트 루프가 계속되는 것을 차단합니다.

악용 될 수있는 방법 :

규칙 3.1과 3.3은 함께 작동하지 않습니다. require()체인에 최대 1kb 및 3 s 를 유지하면 성공하기가 어려워집니다.
규칙 3.2와 3.4는 거의 호환되지 않습니다. 3.4 동기식 호출 금지 3.2 콜백 수를 제한하여 고급 비동기 작업을 어렵게 만듭니다.
규칙 3.4는 모든 정직에서 실제로 따라야하는 규칙입니다. 3.1, 3.2 및 3.3은 완전한 가짜입니다.

자바 스크립트 (ECMAScript)

7.3.2 : 정규식 리터럴

정규식 리터럴을 사용해서는 안됩니다. 특히 소스 코드에는 아래 정의 된 RegularExpression 비 터미널과 일치하는 하위 문자열이 포함되어서는 안됩니다 .

RegularExpression     :: '/' RegularExpressionBody '/'
RegularExpressionBody :: [empty]
                         RegularExpressionBody [any-but-'/']

[empty] 는 빈 문자열과 일치하고 [any-but- '/'] 는 '/'(슬래시, U+002F)를 포함하는 것을 제외한 모든 단일 문자 문자열과 일치합니다 .

이론적 해석

가독성을 위해 정규 표현식을 사용하지 않는 것이 좋습니다. 정규식에 의존하기보다는 전통적인 문자열 연산으로 코드를 이해하는 것이 더 쉬운 경우가 많습니다. 그러나 더 중요한 것은 많은 정규식 엔진이 하위 성능을 제공한다는 것입니다. 정규 표현식은 JavaScript 와 관련된 보안 문제 와도 관련이 있습니다 .

그러나 조직 ™는 정규 표현식 가끔 것을 인식 입니다 작업에 가장 적합한 도구입니다. 따라서 RegExp객체 자체는 금지되지 않습니다.

문법 발췌문의 구문 ([정의 된 것이 아니라])은 ECMAScript 스펙의 구문과 일치합니다. 물론 가상 스펙의 다른 지점에서 더 엄격하게 정의 될 것입니다.

트릭

다음 프로그램이 적합하지 않습니다.

// sgn(x) is -1 if x < 0, +1 if x > 0, and 0 if x = 0.
function sgn(x) {
  return x > 0?  +1
       : x < 0?  -1
       :          0
}

위에 주어진 RegularExpressionBody 비 터미널 의 프로덕션은 명시 적 재귀에 의존하여 BNF로 목록을 표현하는 일반적인 방법을 보여줍니다. 여기서 속임수는 빈 문자열을 RegularExpressionBody 로 "실수로"허용 하여 문자열 //이 소스 코드에서 금지되도록하는 것입니다. 그러나 어쨌든 누가 한 줄짜리 주석이 필요합니까? C89와 CSS는 /* */차단 주석 만 허용하면서 모두 올바르게 작동하는 것 같습니다 .

씨#

12.1 프로그램 상태에 영향을 미치는 정적 메소드는 금지됩니다

정적 메소드의 결과, 특히 일부 상태를 변경하는 메소드를 안정적으로 테스트하기가 어렵 기 때문입니다.

12.2 정적 메소드는 결정 론적이어야한다

정적 메소드가 입력을 가져 와서 출력을 제공하는 경우 동일한 입력으로 정적 메소드를 호출 할 때마다 결과가 동일해야합니다.

왜

C # 프로그램의 진입 점은 전용 정적 메소드 'main'입니다. 첫 번째 규칙에서는 공개, 보호 또는 내부 방법 만이 규칙을 따라야한다는 규칙을 잊어 버리기 때문에 이제는 금지되어 있습니다. 테스트가 실제로 문제가되는 경우 공용 메소드 만 규칙 1을 따라야합니다. 프로그램이 실패하면 프로그램이 오류 코드를 표시하므로 기본적으로 규칙 2를 위반할 수 있습니다. 이는 입력 매개 변수와 독립적으로 발생할 수 있습니다. 예를 들어, 프로그램이 파일을 찾지 못하거나 올바르게 설정되지 않은 다른 시스템에 종속 될 수 있습니다.

자바 / 스프링

4.2 생산 코드에서 리플렉션 사용

리플렉션을 사용하여 소스 코드의 제한된 부분에 액세스 할 수 있으므로 프로덕션 코드에서 리플렉션을 사용하는 것은 엄격히 금지됩니다.

간계

Spring은 기술적으로 리플렉션을 사용하여 지원하는 객체를 인스턴스화하고 관리합니다. 이 규칙을 적용하면 모든 Spring 유틸리티를 제거해야합니다.

웹 사이트 인코딩

666.13 UTF-8은 UTF-7을 사용해서는 안되고 UTF-7로 대체해야합니다
. UTF-7은 특히 우리가하는 아랍 국가 사용자를 대상으로 할 때 UTF-8보다 효율적입니다.

악용 될 수있는 방법 :

HTML5는 특히 UTF-7을 허용하지 않습니다. 즉, 최신 브라우저는이를 지원하지 않습니다. 모든 테스트가 IE 11과 같은 브라우저에서 수행되면 너무 늦을 때까지 아무도 알 수 없습니다.

자바 스크립트 비트 연산자

1.9 곱셈이나 나눗셈 또는 바닥은 비트 단위보다 훨씬 빠르지 않은 한 사용하지 않아야합니다. 비트 연산자 <<, >> 및 ~~로 각각 대체해야합니다.
근거 : 비트 연산자가 더 효율적입니다.

악용 될 수있는 방법 :

곱하기 또는 나누기 대신 << 또는 >>를 사용하면 많은 수를 처리 할 때 문제가 발생할 수 있습니다. 또한 작업 우선 순위와 소수점을 무시합니다. 이중 물결표는 음수를 지정하면 다른 값을 반환합니다.

자바 스크립트 (ECMAScript)

7.3.1 : 식별자 규칙

식별자 유형에 따라 식별자가 제한됩니다. 식별자는 변수 , 상수 , 함수 및 생성자 유형으로 나뉩니다 . 5.3 참조 제한 사항은 다음과 같습니다.

• 변수 : 첫 문자는 소문자 여야합니다. 낙타 문자 (1.3 참조)는 식별자 내에서 단어를 구분하는 데 사용해야합니다.

• 상수 : 식별자는 대문자와 밑줄 ( '_', U+005F) 로만 구성되어야합니다 . 식별자 내에서 단어를 구분하려면 밑줄을 사용해야합니다.

• 기능 : 기능은 식별자 유형 과 동일한 규칙을 따라야합니다 .

• 생성자 : 첫 번째 문자는 대문자 여야합니다. 낙타 문자 (1.3 참조)는 식별자 내에서 단어를 구분하는 데 사용해야합니다.

이론적 해석

읽을 수있는 식별자 이름은 유지 관리에 매우 중요합니다. 식별자를 잘 알려진 규칙으로 제한하면 다른 코드 기반 간 전환이 쉬워집니다. 이러한 특정 규칙은 Java ™ 프로그래밍 언어에 대한 표준 규칙에 따라 모델링됩니다 [1] .

트릭

"글로벌 jQuery 객체"의 가장 일반적인 이름이이 이름 규칙과 충돌한다는 것을 jQuery 팀에 알리는 것이 유감입니다. 다행히, 그들은 이미 생각하고 모두를 제공 한 $및 jQuery글로벌 이름으로 같은 객체를 참조. 나는 userbase가이 전환 날카로운로하지 않을 수도 있다는 상상 $을 jQuery하지만, 사방.