C / C++ 컴파일러 경고: 코드를 모두 정리하여 제거하시겠습니까, 아니면 그대로 두십니까?

C / C++ 컴파일러 경고: 코드를 모두 정리하여 제거하시겠습니까, 아니면 그대로 두십니까?

나는 다른 사람들로부터 업데이트 코드를 받은 많은 프로젝트에서 일했다.종종 나는 그것을 컴파일하고 약 1,000개 이상의 컴파일러 경고를 받는다.컴파일러 경고를 보면 기분이 더러워지기 때문에, 내 첫 번째 임무는 코드를 정리하고 그것들을 모두 제거하는 것이다.일반적으로 나는 초기화되지 않은 변수와 같은 12가지 문제를 발견한다.

나는 왜 사람들이 그것들을 놔두고 경고 없이 완벽하게 깨끗한 컴파일이 없는지 이해할 수 없다.내가 뭘 빼놓았나요?그냥 두고 갈 만한 타당한 이유가 있을까?무서운 이야기라도 있어?

나는 어떤 경고라도 치울 것이다.당신이 알고 있는 것들도 (그런 것이 존재한다면) 누가 코드를 컴파일하든 당신에게 나쁜 인상을 줄 것이다.

내가 만약 다른 사람의 코드를 작업해야 한다면 내가 찾을 "미소" 표지 중 하나야.

실제 오류나 잠재적인 미래 문제가 아니라면, 그것은 슬럼프의 징후일 것이다.

그들이 진짜 문제를 나타내지 않더라도 그들을 깨끗이 치워라.그렇지 않으면, 만약 진짜 문제를 나타내는 경고가 나타나면, 당신은 모든 소음을 통해 그것을 보지 못할 것이다.

나는 모든 경고를 없애는 것이 최선이라는 것에 동의한다.수천 개의 경고를 받는다면 우선 해결 방법을 정해야 한다.

컴파일러를 가장 낮은 경고 수준으로 설정하기 시작하십시오.이러한 경고가 가장 중요해야 한다.이 경고가 고정되면 경고 수준을 높이고 가장 높은 경고 수준에 도달할 때까지 반복하십시오.그런 다음 경고가 오류로 처리되도록 컴파일 옵션을 설정하십시오.

당신이 무시해도 안전하다고 생각하는 경고를 발견하면, 당신의 이론을 검증하기 위해 몇 가지 조사를 하라.그런 다음에만 비활성화하고 가능한 최소의 방법으로만 비활성화하십시오.대부분의 컴파일러는#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에서 컴파일러를 컴파일한 코드베이스에 대해 작업해 본 적이 있다.) 하지만 항상 가능하지는 않다.컴파일러가 그냥 잘못된 경우(HP-UX ACC on Itanium, 나는 너를 보고 있다)를 본 적이 있지만, 그런 경우는 분명히 드물다.다른 사람들이 주목하듯이, 그러한 상황에서는 경고를 비활성화할 수 있다.

이 버전의 컴파일러에서 경고하는 것은 다음 버전에서 오류가 될 수 있으므로(gcc 3.x에서 4.x로 업그레이드하는 사람은 그것에 익숙해야 함) 지금 정리하십시오.

일부 컴파일러는 특정 상황에서 문제가 될 수 있는 정말 유용한 경고를 방출할 것이다. Visual C++ 2005와 2008은 오늘날 엄청난 이점인 64비트 문제에 대해 경고할 수 있다.64비트로 마이그레이션할 계획이 있다면, 이러한 종류의 경고를 정리하는 것만으로도 포트 시간이 획기적으로 단축될 것이다.

내가 경고문을 코드로 남길 경우나 청소할 수 없는 경우(내가 할 수 있는 경고를 제거하긴 하지만)가 있다.예를 들면 다음과 같다.

• 현재 진행 중인 작업이 있고, 작업/관심이 더 필요하다는 것을 알고 있다면, 이 작업이 적절할 수 있음을 나타내는 경고를 남겨두십시오.
• /clr로 C++를 컴파일하는 경우 기본 코드가 생성되는 사항에 대한 몇 가지 경고가 있으며, 코드베이스를 기능적으로 변경할 수 없을 때 이러한 경고를 모두 억제하는 것이 번거로울 수 있다.
• 해결 방법을 모를 때 경고 정리PC-린트 경고로 몇 번 해봤는데 결국 버그를 도입했다.변경의 정확한 효과가 무엇인지 모르는 경우(예: 경고를 제거하기 위한 C-스타일 깁스)는 하지 마십시오.경고를 알아내거나 암호를 그냥 두라는 게 내 조언이야.

어쨌든, 그러한 예들은 내 머리 위에 경고를 남기는 것이 적절할 것 같은 경우들이다.

가장 나쁜 점은 코드를 새로 쓸 때 실수로 경고를 더 많이 넣었는지 알기가 어렵다는 것이다. 어차피 경고를 무시하는 경우가 너무 많기 때문이다.

그것들을 모두 치우는 것의 문제점은 당신이 가질 수도 있고 갖지 않을 수도 있는 시간이 걸린다는 것이다.하지만, 일반적으로 가능한 한 많이 청소해야 해.

고칠 시간이 없어 코드에 경고를 남기는 것은 아침에 시간이 부족해서 이를 닦지 않는 것과 같다.그것은 코드위생의 기본적인 문제다.

항상 경고를 정리하십시오.경고가 정상임을 알고 있는 특정 사례가 있는 경우 해당 경우에만 경고를 억제하십시오.

일부 경고는 양성일 수 있지만, 대부분은 코드의 실제적인 문제를 나타낸다.

만약 당신이 당신의 경고를 모두 치우지 않는다면, 경고 리스트는 계속해서 증가할 것이고 실제 문제들은 경고 소음의 바다에서 사라질 것이다.

정말 훌륭한 프로그래머의 특징 중 하나는 나쁜 코드가 그들에게 메스꺼움을 준다는 것이다.

나는 컴파일러뿐만 아니라 IDE 내부도 깔끔하게 정리하려고 노력한다.내가 도구보다 더 잘 알고 있다면 경고 인스턴스를 억제해야 할 때도 있지만, 적어도 그것 또한 문서화 역할을 한다.

항상 모든 경고를 활성화한 다음 경고가 있을 경우 내 프로젝트를 중지하도록 설정하십시오.

만약 경고가 있다면, 각각의 경고를 확인하여 문제가 없는지 확인해야 한다.이것을 반복하는 것은 시간 낭비다.이것을 하지 않는 것은 당신의 코드에 서서히 오류가 발생하게 할 것이다.

경고를 제거하는 방법이 있다(예: #pragma arggsused).

컴파일러가 그 일을 하게 하라.

나는 경고가 불안정, 충돌 또는 메모리 손상을 초래할 수 있는 여러 임베디드 시스템과 함께 일했다.그 경고가 무해하다는 것을 모르는 한, 그것은 다루어져야 한다.

경고는 버그로 취급되어야 한다.만약 당신이 당신의 경고를 제거할 만큼 충분히 코드를 잘 부호화할 수 없다면, 당신은 아마도 코드를 부호화하지 말아야 할 것이다.나의 조에서 우리는 모든 경고를 오류로 강제하는 결정을 내렸다.그것은 이 논의를 완전히 끝내고 정말로 IMHO는 코드 품질을 개선한다.

나는 경고를 싫어한다.나는 가능한 한 그것들을 제거한다.
때때로, 일을 끝내야 한다는 압박감에 시달릴 때, 나는 그들 중 몇 명을 남겨둔다.하지만 나는 그들을 거의 떠나지 않는다.남은 게 있으면 더러워지는 너처럼 느껴져.

내가 작업하는 코드베이스에는 4000개 이상의 경고가 있다.그들 중 몇몇은 합법적인 문제들이다.우리는 절대 그것들을 수리할 시간이 주어지지 않고, 다른 부서진 것들을 리액터링할 시간도 주어지지 않는다...부분적으로는 코드가 너무 오래되어 표준화된 C++보다 앞서 있기 때문이다.우리는 VC++ 6으로만 컴파일할 수 있다.

항상 모든 경고를 정리하거나 필요한 경우 명시적으로 억제하십시오.경고에 대한 기본 설정은 컴파일할 때 가장 높을 수 있어야 한다(예: VS에 대한 수준 4).

내가 지금 유지하고 있는 코드를 만든 사장님.그는 자신의 타락 경고를 감추기 위해 컴파일러 깃발을 사용한다.

나는 시간이 날 때 내가 할 수 있는 것을 정리한다.

나는 상당히 높은 수준의 경고로 코드를 컴파일하여 정리하려고 하는데, "서명된/서명되지 않은 비교" 경고는 제외하고, 이 경고는 반드시 고쳐야 하지만 결코 귀찮게 할 수 없다.

짧은 버전:g++에서 나는 "-Wextra -Wno-sign-compare"를 사용하고 모든 메시지를 제거한다.

참조URL: https://stackoverflow.com/questions/183788/c-c-compiler-warnings-do-you-clean-up-all-your-code-to-remove-them-or-leave