코드 개선을 위한 지침

https://stackoverflow.com/questions/60673

09-06-2019
|

문제

코드의 전반적인 품질을 향상시키기 위해 어떤 지침을 따르나요?많은 사람들이 C++ 코드를 작성하는 방법에 대해 (아마도) 실수를 더 어렵게 만드는 규칙을 갖고 있습니다.나는 사람들을 본 적이 있다 주장하다 그 모든 if 명령문 뒤에는 중괄호 블록({...}).

다른 사람들이 따르는 지침과 그 이유에 관심이 있습니다.나는 또한 당신이 쓰레기라고 생각하지만 일반적으로 지켜지는 지침에도 관심이 있습니다.누구든지 몇 가지를 제안할 수 있나요?

공을 굴리기 위해 먼저 몇 가지 사항을 언급하겠습니다.

매회마다 항상 중괄호를 사용하십시오. if / else (위에서 언급한) 진술.이에 대한 근거는 단일 문이 실제로 하나의 문인지 또는 둘 이상의 문으로 확장되는 전처리기 매크로인지 구별하는 것이 항상 쉬운 것은 아니므로 이 코드는 깨질 수 있다는 것입니다.

    // top of file:
    #define statement doSomething(); doSomethingElse

    // in implementation:
    if (somecondition)
        doSomething();

하지만 중괄호를 사용하면 예상대로 작동합니다.

조건부 컴파일에만 전처리기 매크로를 사용하세요.전처리기 매크로는 C++ 범위 지정 규칙을 허용하지 않기 때문에 온갖 종류의 지옥을 초래할 수 있습니다.헤더 파일에 공통 이름이 있는 전처리기 매크로 때문에 여러 번 당황했습니다.조심하지 않으면 온갖 종류의 혼란을 초래할 수 있습니다!

이제 당신에게로 넘어갑니다.

해결책

제가 개인적으로 좋아하는 몇 가지:

다음과 같은 코드를 작성하려고 노력하세요. const 올바른.수정하기 쉽지만 때로는 고통스러운 버그를 제거하는 데 도움이 되는 컴파일러를 사용하게 됩니다.또한 귀하의 코드는 귀하가 작성한 당시 염두에 두었던 내용을 말해줍니다. 이는 신규 사용자나 관리자가 떠난 후 유지관리자에게 유용합니다.

메모리 관리 사업에서 벗어나세요.스마트 포인터 사용 방법 알아보기: std::auto_ptr, std::tr1::shared_ptr (또는 boost::shared_ptr) 그리고 boost::scoped_ptr.둘 사이의 차이점과 사용 시기와 사용 시기를 알아보세요.또 다른.

아마도 표준 템플릿 라이브러리를 사용하게 될 것입니다.읽기 Josuttis 책.STL을 알고 있다고 생각하면서 컨테이너에 대한 처음 몇 장을 읽고 나서 멈추지 마십시오.좋은 일을 추진하십시오.알고리즘과 함수 객체.

다른 팁

불필요한 코드를 삭제하세요.

그게 전부입니다.

공통 코딩 스타일과 지침을 사용하고 시행합니다. 이론적 해석: 팀이나 회사의 모든 개발자는 다양한 버팀대 스타일 등으로 인해 발생할 수 있는 방해 없이 코드를 읽을 수 있습니다.
전체 소스 기반을 정기적으로 전체 재구축합니다(예:매일 빌드를 수행하거나 각 체크인 후에 빌드하고 오류를 보고하세요! 이론적 해석: 소스는 거의 항상 사용 가능한 상태이며 문제가 "구현"된 직후에 문제가 감지되므로 문제 해결 비용이 저렴합니다.

컴파일러(gcc: -Wall 좋은 시작이지만 모든 내용이 포함되어 있지 않으므로 문서를 확인하고 오류를 만들어 수정해야 합니다(gcc: -Werror).

이 답변 중 하나에서 언급된 Google의 스타일 가이드는 매우 견고합니다.쓸데없는 내용도 있지만 나쁜 것보다는 좋은 게 더 많거든요.

Sutter와 Alexandrescu는 이 주제에 관해 괜찮은 책을 썼습니다. C++ 코딩 표준.

다음은 lil' ole me가 알려주는 몇 가지 일반적인 팁입니다.

들여쓰기와 괄호 스타일이 모두 잘못되었습니다.다른 사람들도 마찬가지입니다.따라서 이에 대한 프로젝트 표준을 따르십시오.자존심을 삼키고 모든 것이 코드베이스의 나머지 부분과 최대한 일치하도록 편집기를 설정하십시오.일관되지 않게 들여쓰기된 코드를 읽는 것은 정말 짜증나는 일입니다.즉, 괄호와 들여 쓰기는 "코드 개선"과 관련이 없습니다. 다른 사람들과 함께 일할 수있는 능력을 향상시키는 것입니다.
댓글을 잘 쓰세요.이것은 매우 주관적이지만 일반적으로 다음에 대한 의견을 작성하는 것이 좋습니다. 왜 코드는 자신이 하는 일을 설명하는 것이 아니라 자신이 하는 방식대로 작동합니다.물론 복잡한 코드의 경우 알고리즘이나 코드에 익숙하지 않은 프로그래머가 무엇 그것도 하고 있어요.사용된 알고리즘에 대한 설명 링크는 매우 환영합니다.
가능한 한 간단한 방식으로 논리를 표현합니다.아이러니하게도 "상수를 비교의 왼쪽에 배치"와 같은 제안이 여기서 잘못되었다고 생각합니다.매우 인기가 있지만 영어 사용자의 경우 읽기에 대한 프로그램의 논리적 흐름을 깨뜨리는 경우가 많습니다.자신(또는 컴파일러)이 동등 비교를 올바르게 작성하는 것을 믿을 수 없다면 반드시 이와 같은 트릭을 사용하십시오.하지만 그렇게 하면 명확성이 희생됩니다.또한 이 범주에 속하는 것은 다음과 같습니다."내 논리에 3단계 들여쓰기가 있나요?더 간단할 수 있을까요?" 유사한 코드를 함수에 적용합니다.어쩌면 기능을 분할할 수도 있습니다.기본 논리를 우아하게 표현하는 코드를 작성하려면 경험이 필요하지만 노력할 가치가 있습니다.

그것들은 꽤 일반적이었습니다.구체적인 팁에 대해서는 Sutter와 Alexandrescu보다 훨씬 더 나은 일을 할 수 없습니다.

if 문에서 상수를 왼쪽에 배치합니다. 즉,

if( 12 == var )

~ 아니다

if( var == 12 )

'='를 입력하지 않으면 할당이 되기 때문입니다.최상위 버전에서는 컴파일러가 이것이 불가능하다고 말하고 후자에서는 실행되며 if는 항상 true입니다.

나는 if가 같은 줄에 있지 않을 때마다 중괄호를 사용합니다.

if( a == b ) something();
if( b == d )
{
    bigLongStringOfStuffThatWontFitOnASingleLineNeatly();
}

열기 및 닫기 중괄호는 항상 자체 줄을 갖습니다.그러나 그것은 물론 개인적인 관례이다.

코드가 수행하는 작업을 설명하는 데만 필요한 경우에만 주석을 달고 코드를 읽어도 동일한 내용을 알 수 없습니다.

더 이상 사용하지 않는 코드를 주석 처리하지 마세요.이전 코드를 복구하려면 소스 제어 시스템을 사용하세요.코드를 주석 처리하면 상황이 지저분해 보이고 실제로 중요한 주석이 주석 처리된 코드의 배경 속으로 사라져 버립니다.

일관된 형식을 사용하세요.
레거시 코드 작업 시 기존 형식 지정 스타일을 사용합니다.브레이스 스타일.
Scott Meyer의 저서 Effective C++ 사본을 받으세요.
Steve MConnell의 책 Code Complete의 사본을 구하십시오.

좋은 것도 있어요 C++ 스타일 가이드 여기에 언급된 대부분의 규칙이 포함되어 있으며 Google에서 내부적으로 사용됩니다.

많은 주석을 작성하기 시작하세요. 하지만 이를 코드를 자체 설명이 가능하도록 리팩토링하는 기회로 활용하세요.

즉:

for(int i=0; i<=arr.length; i++) {
  arr[i].conf() //confirm that every username doesn't contain invalid characters
}

좀 더 비슷했어야 했는데

for(int i=0; i<=activeusers.length; i++) {
  activeusers[i].UsernameStripInvalidChars()
}

들여 쓰기에는 탭을 사용하지만 공간에 데이터를 정렬하면 사람들은 탭 크기를 변경하여 계약을 맺을 수있는 금락을 결정할 수 있지만 물건이 정렬되어 있음을 의미합니다 (예 : 값을 구조물)
가능한 경우 매크로 대신 항상 상수나 인라인 함수를 사용하세요.
헤더 파일에서 'using'을 사용하지 마십시오. 헤더를 포함하는 사람이 전역 네임스페이스에서 모든 표준(예:)을 원하지 않더라도 해당 헤더를 포함하는 모든 항목도 영향을 받기 때문입니다.

내용이 약 80열보다 길면 여러 줄로 나눕니다. 예:

if(SomeVeryLongVaribleName != LongFunction(AnotherVarible, AString) &&
   BigVaribleIsValid(SomeVeryLongVaribleName))
{
    DoSomething();
}

사용자가 기대하는 작업을 수행하도록 하는 연산자만 오버로드합니다. 예를 들어 2dVector에 대한 + 및 - 연산자를 오버로드하는 것은 괜찮습니다.
단지 다음 블록이 무엇을 하는지 알려주기 위한 것일지라도 항상 코드에 주석을 달아주세요(예: "이 레벨에 필요하지 않은 모든 텍스처 삭제").누군가는 나중에 작업해야 할 수도 있습니다. 아마도 당신이 떠난 후에 그들은 무엇을 하고 있는지를 나타내는 주석이 없는 1000줄의 코드를 찾고 싶지 않을 것입니다.

코딩 규칙을 설정하고 관련된 모든 사람이 규칙을 따르도록 합니다. (다음 명령문/표현식이 제대로 들여쓰기되지 않았기 때문에 코드를 읽는 것을 원하지 않을 것입니다.)
지속적으로 코드를 리팩터링합니다(Martin Fowler가 저술한 Refactoring 사본을 구하세요. 장단점은 책에 자세히 설명되어 있습니다).
느슨하게 결합된 코드 작성(자명한 코드를 작성하여 주석 작성을 피하십시오. 느슨하게 결합된 코드는 변경 관리/적응이 더 쉬운 경향이 있습니다)
가능하다면 코드를 단위 테스트하세요(또는 충분히 마초라면 TDD).
일찍 릴리스하다, 자주 릴리스하다
조기 최적화 방지(프로파일링은 최적화에 도움이 됨)

비슷한 맥락에서 여기에서 몇 가지 유용한 제안을 찾을 수 있습니다. 잘못된 코드를 잘못된 것처럼 보이게 만드는 방법은 무엇입니까?의미 오류를 방지하기 위해 어떤 패턴을 사용합니까?

가능한 경우 사후 증가 대신 사전 증가를 사용하십시오.

저는 C++ 프로젝트에서 PC-Lint를 사용하며 특히 MISRA 지침이나 Scott Meyers의 "Effective C++" 및 "More Effective C++"와 같은 기존 출판물을 참조하는 방식을 좋아합니다.정적 분석 도구가 검사하는 각 규칙에 대해 매우 자세한 근거를 작성할 계획이더라도 사용자가 신뢰하는 확립된 출판물을 가리키는 것이 좋습니다.

다음은 C++ 전문가가 제공한 가장 중요한 조언입니다. 이 조언은 몇 가지 중요한 경우에 내 코드에서 버그를 찾는 데 도움이 되었습니다.

메소드가 다음과 같은 경우 const 메소드를 사용하십시오. 가정되지 않은 개체를 수정합니다.
객체가 다음과 같은 경우 매개변수에 const 참조와 포인터를 사용하세요. 가정되지 않은 개체를 수정합니다.

이 두 가지 규칙을 사용하면 컴파일러는 코드에서 논리에 결함이 있는 위치를 무료로 알려줍니다!

또한 몇 가지 좋은 기술을 따르려면 구글 블로그 '화장실 테스트'.

6개월 뒤에 보세요

들여쓰기가 제대로 되었는지 확인하세요

흠 - 좀 더 구체적으로 말했어야 했는데.

나는 나 자신을 위한 조언을 별로 구하지 않습니다. 나는 정적 코드 분석 도구를 작성하고 있으며(현재 상용 제품은 내가 원하는 것에 충분하지 않습니다) 가능한 것을 강조할 플러그인에 대한 아이디어를 찾고 있습니다. 코드에 오류가 있습니다.

여러 사람들이 const 정확성과 스마트 포인터 사용과 같은 것들을 언급했습니다. 이것이 제가 확인할 수 있는 종류의 생각입니다.들여쓰기와 주석 달기를 확인하는 것은 (어쨌든 프로그래밍 관점에서 보면) 조금 더 어렵습니다.

스마트 포인터는 소유권을 매우 명확하게 나타내는 좋은 방법을 제공합니다.클래스나 함수인 경우:

당신이 얻을 경우 원시 포인터, 당신은 아무것도 소유하지 않습니다.당신은 포인트가 당신보다 오래 살아남을 것이라고 보장하는 호출자의 호의에 따라 포인트를 사용할 수 있습니다.
당신이 얻을 경우 약한_ptr, 귀하는 포인트를 소유하고 있지 않으며, 게다가 포인트는 언제든지 사라질 수 있습니다.
당신이 얻을 경우 shared_ptr, 귀하는 다른 사람과 함께 해당 개체를 소유하므로 걱정할 필요가 없습니다.스트레스도 적고 통제력도 약합니다.
당신이 얻을 경우 auto_ptr, 귀하는 해당 개체의 유일한 소유자입니다.그것은 당신 것입니다, 당신은 왕입니다.당신은 그 물건을 파괴하거나 다른 사람에게 줄 수 있는 권한을 가지고 있습니다(그러면 소유권을 잃게 됩니다).

나는 auto_ptr의 경우가 특히 강력하다고 생각합니다.디자인에서 auto_ptr을 보면 해당 개체가 시스템의 한 부분에서 다른 부분으로 "방황"할 것임을 즉시 알 수 있습니다.

이것은 적어도 내 애완동물 프로젝트에서 사용하는 논리입니다.주제에 대해 얼마나 많은 변형이 있을 수 있는지 잘 모르겠지만 지금까지는 이 규칙 세트가 나에게 도움이 되었습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow