저는 다른 사람들이 코드를 업데이트 한 많은 프로젝트에서 일해 왔습니다. 자주 컴파일하지 않고 약 1,000 개 이상의 컴파일러 경고를받습니다. 컴파일러 경고를 보았을 때 그들은 나를 더러워지게 만들었고, 그래서 나의 첫 번째 임무는 코드를 정리하고 모두 제거하는 것이다. 일반적으로 초기화되지 않은 변수와 같은 12 가지 문제가 있습니다.C/C++ 컴파일러 경고 : 모든 코드를 제거하여 제거하거나 그대로 두겠습니까?
나는 사람들이 왜 그들을 떠나고 경고없이 완벽하게 깨끗한 컴파일을하지 않는지 이해하지 못한다. 내가 놓친 게 있니? 그 (것)들을 남겨 둘 유효한 정당한 이유 있는가? 공유 할 공포 이야기?
경고를 정리합니다. 당신이 알고있는 것조차도 무해한 것 (그런 것이 있다면)은 누구든지 코드를 컴파일 할 사람에게 나쁜 인상을 줄 것입니다.
누군가 다른 사람의 코드로 작업해야한다면 "냄새 나는"징후 중 하나입니다.
그렇지 않은 경우 실제 오류 또는 잠재적 인 미래 문제, 그것은 sloppiness
내가 경고를 싫어하는+1이이 게시물에 일반적으로. 내가 추가 할 수있는 유일한 것은 "해가없는"컴파일러 경고가 있으면 더 위험한 경고를 숨길 수있는 "노이즈"가 많이 생성된다는 것입니다. – Nick
오른쪽. 당신은 그들 모두를 조사하고, 부러진 것들을 고치십시오. 어떤 새로운 것들이 무시되지 않도록, 당신은 무해한 것들을 침묵시켜야합니다. – wnoise
오른쪽 위. 나는 중요한 것들로부터 나의 관심을 앗아가는 "시각적 잡음"이라는 경고를 생각한다. 그래서 나는 우리 모두가 "내가 알아, 나도 알아, 그건 문제가 아니야." – Dan
의 표시 일 것이다. 나는 가능한 한 그들을 제거합니다.
때로는 일을 끝내야한다는 압박감이들 때, 나는 그 중 일부를 남겨 둡니다. 나는 거의 그들을 떠난다. 나는 너처럼 느껴진다. 왼쪽이 더러워지면 더럽다.
내 작업에서 경고를 오류로 처리하도록 컴파일러 설정이 켜져 있습니다. 따라서 경고가 없거나 컴파일되지 않습니다.
* * 모든 프로젝트에 있어야합니다. – Andrew
윈도우에서는 MFC를 사용할 수없고 모든 'C'표준 lib 함수를 MS의 s_versions로 변경해야합니다. –
예. 그러나 개인 프로젝트의 경우 #pragma를 사용하여 보안 경고를 추가해야합니다. _s 버전은 실제로 안전하지 않으며 이식성이 떨어지고 느립니다. –
항상 경고를 정리하십시오. 경고가 정상임을 알 수있는 특별한 경우에는 해당 인스턴스에 대해서만 경고 메시지를 표시하지 마십시오.
일부 경고는 심각하지 만 대부분의 경우 코드에 실제 문제가 있음을 나타냅니다.
경고를 모두 지우지 않으면 경고 목록이 계속 커지고 실제 문제는 경고음이 울리는 곳에서 사라집니다.
내가 작업하는 코드베이스에는 4000 가지 이상의 경고가 있습니다. 그들 중 일부는 정당한 문제입니다. 우리는 결코 들어가서 고칠 수있는 시간이나 다른 부러진 것들을 리펙토링 할 시간이 없습니다 ... 부분적으로 이것은 코드가 표준화 된 C++보다 오래되기 때문입니다. 우리는 VC++ 6 만 컴파일 할 수 있습니다.
정말 좋은 프로그래머의 특징 중 하나는 잘못된 코드로 인해 위장이 나빠질 수 있다는 것입니다.
필자는 모든 코드를 컴파일러에서 지울뿐만 아니라 상당히 까다로운 수준으로 설정 한 IDE에서 깨끗하게하려고 노력합니다. 때로는 경고 인스턴스를 억제해야하지만 도구보다 잘 알고 있지만 최소한 설명서도 제공합니다.
최악의 경우는 새로운 코드를 작성할 때 우연히 더 많은 경고를 도입했는지 알기가 어렵다는 것입니다. 어쨌든 많은 코드를 무시하기 때문에.
문제를 해결하는 데는 시간이 걸릴 수도 있고 없을 수도 있습니다. 하지만 네, 일반적으로 가능한 한 많은 것을 정리해야합니다.
실제 문제를 나타내지는 않지만 정리하십시오. 그렇지 않으면 이이라는 실제 경고가 나타나면 모든 잡음을 통해이를 볼 수 없습니다.
경고는 버그로 간주되므로주의해야합니다.경고를 없애기에 충분히 코드를 작성할 수 없다면 코딩을해서는 안됩니다. 우리 그룹에서는 모든 경고를 오류로 강제하기로 결정했습니다. 이 토론을 끝내고 실제로 IMHO는 코드 품질을 향상시킵니다.
항상 모든 경고를 지우거나 필요한 경우 경고를 명시 적으로 억제하십시오. 경고의 기본 설정은 컴파일 할 때 가능한 한 높아야합니다 (예 : VS의 레벨 4).
모든 경고를 제거하는 것이 가장 좋습니다. 수천 가지 경고가 나오면 수정 사항의 우선 순위를 정해야합니다.
컴파일러를 가장 낮은 경고 수준으로 설정하십시오. 이러한 경고가 가장 중요합니다. 문제가 해결되면 경고 수준을 높이고 가장 높은 경고 수준에 도달 할 때까지 반복합니다. 그런 다음 경고가 오류로 처리되도록 컴파일 옵션을 설정하십시오.
무시할 수 있다고 의심되는 경고를 발견하면 이론을 검증하기위한 조사를 수행하십시오. 그런 다음 가능한 최소한의 방법으로 만 사용 중지하십시오. 대부분의 컴파일러는 #pragma 지시문을 사용하여 파일의 일부분 만 경고를 활성화/비활성화 할 수 있습니다. Visual C++ 예제는 다음과 같습니다.
typedef struct _X * X; // from external header, not 64-bit portable
#pragma warning(push)
#pragma warning(disable: 4312) // 64-bit portability warning
X x = reinterpret_cast<X>(0xDDDDDDDD); // we know X not 64-bit portable
#pragma warning(pop)
단 한 줄의 코드에 대해서만 경고를 비활성화합니다. 이 방법을 사용하면 나중에 코드를 변경하여 간단한 텍스트 검색을 수행 할 수 있습니다.
일반적으로 단일 파일이나 모든 파일에 대해 특정 경고를 비활성화 할 수 있습니다. IMHO 이것은 위험하며 최후의 수단이어야합니다.
가능하면 을 청소하십시오.. 멀티 플랫폼/멀티 컴파일러 코드베이스 (필자는 6 개의 다른 컴파일러가있는 7 개의 다른 OS에서 컴파일 된 코드를 작성했습니다)는 항상 가능하지는 않습니다. 나는 컴파일러가 단지 인 경우를 보았습니다. (Itanium에서 HP-UX aCC, 나는 당신을보고 있습니다.)하지만 그것은 드문 경우입니다. 다른 사람들이 알 수 있듯이 이러한 상황에서는 경고를 비활성화 할 수 있습니다.
이 버전의 컴파일러에서 경고가 나오는 것은 다음 버전에서 오류가 될 수 있습니다 (gcc 3.x에서 4.x로 업그레이드하는 모든 사용자는 이에 익숙해야합니다).
일부 컴파일러는 특정 상황에서 문제가되는 유용한 경고를 방출합니다. Visual C++ 2005 및 2008은 요즘 커다란 이점 인 64 비트 문제에 대해 경고 할 수 있습니다. 이러한 종류의 경고를 정리하면 64 비트로 마이그레이션 할 계획이 있으므로 포트 시간이 크게 단축됩니다.
코드에서 경고를 남기거나 (내가 할 수있는 경고를 제거하더라도) 오류를 지울 수없는 경우가 있습니다. 예를 들면 :
어쨌든, 내 머리 꼭대기에서 벗어난 경고로 경고를 남기는 것이 적절할 수 있습니다.
나는 이것을 투표하고 있습니다. 왜냐하면 Nick은 다음과 같이 위험한 플래그가있는 코드를 사용해서는 안되는 다음과 같은 매우 중요한 경우를 언급했기 때문입니다. "수정 사항을 이해하지 못할 때 경고를 지우십시오" – pestophagous
저는 경고 때문에 불안정, 충돌 또는 메모리 손상이 발생할 수있는 많은 임베디드 시스템에서 작업했습니다. 경고가 무해하다는 것을 모르는 경우를 제외하고는 반드시 처리해야합니다.
아침에 충분한 시간이 없기 때문에 수정해야 할 시간이 없으므로 코드에 경고를 남기면 치아를 닦지 않는 것과 같습니다. 이것은 코드 위생의 기본 문제입니다.
항상 모든 경고를 사용하도록 설정 한 다음 경고가있는 경우 건물을 중지하도록 프로젝트를 설정합니다.
경고가있는 경우 문제가 없는지 각 경고를 확인해야합니다. 이 작업을 반복하는 것은 시간 낭비입니다. 이 방법을 사용하면 코드에 오류가 생길 수 있습니다.
경고를 삭제하는 방법이 있습니다 (예 : #pragma argsused).
컴파일러에서 작업하게하십시오.
내가 유지 관리하는 코드를 만든 내 상사. 그는 컴파일 경고를 사용하여 자신의 평결 경고를 숨 깁니다.
시간이 지나면 할 수있는 일을 정리합니다.
상당히 높은 수준의 경고를 사용하여 코드를 컴파일하고 "서명/서명되지 않은 비교"경고를 제외하고 모두 정리하려고합니다. 문제는 해결해야하지만 결코 괴롭히지 않아야합니다.
짧은 버전 : g ++에서 "-Wextra -Wno-sign-compare"를 사용하고 모든 메시지를 제거합니다.
아마도 더 나은 질문은 "경고를 수정합니까, 아니면 그럴 수 있습니까?" – ilitirit
참고 자료로 Demeyer 외의 가치있는 저서 ** 객체 지향적 인 리엔지니어링 패턴 **을 읽어 보시기 바랍니다. al. (레거시 코드 작업자를위한 [무료 전자 서적] (http://scg.unibe.ch/download/oorp/)). 그는 변화의 우선 순위를 매기고 가장 중요한 변화를 우선적으로 그리고 반복적 인 방식으로 작업 할 것을 제안합니다. 따라서, 대답은 프로젝트 시간 상자와 내가 생각하는 우선 순위에 달려있다. –
또한, gcc의 경우, 적어도'-Wall'에서 항상 실행되어야합니다. 나는'-Wextra'를 선호하며 때로는'-pedantic'도 도움이됩니다. –