C / C ++ 컴파일러 경고 : 모든 코드를 정리하여 제거하거나 그대로 두십니까?
나는 다른 사람들이 업데이트 할 코드를받은 많은 프로젝트에서 일했습니다. 자주 나는 그것을 컴파일하고 약 1,000 개 이상의 컴파일러 경고를받습니다. 컴파일러 경고를 보면 더럽게 느껴지므로 첫 번째 작업은 코드를 정리하고 모두 제거하는 것입니다. 일반적으로 나는 초기화되지 않은 변수와 같은 수십 가지 문제를 발견합니다.
나는 사람들이 왜 그들을 남겨두고 경고없이 완벽하게 깨끗한 컴파일을하지 않는지 이해하지 못한다. 내가 뭔가를 놓치고 있습니까? 그냥 떠나야 할 타당한 이유가 있습니까? 공유 할 공포 이야기가 있습니까?
나는 경고를 정리할 것입니다. 당신이 알고있는 것조차 무해하다 (만약 존재한다면) 코드를 컴파일 할 사람에게 나쁜 인상을 줄 것이다.
다른 사람이 코드 작업을해야한다면 찾아 볼 "냄새 나는"신호 중 하나입니다.
실제 오류나 잠재적 인 미래 문제가 아니라면 엉성함의 신호일 것입니다.
실제 문제를 나타내지 않더라도 정리하십시오. 그렇지 않으면 실제 문제를 나타내는 경고 가 표시되면 모든 소음을 통해 확인할 수 없습니다.
내 작업에서는 경고를 오류로 처리하는 컴파일러 설정이 켜져 있습니다. 따라서 경고가 없거나 컴파일되지 않습니다. :)
모든 경고를 제거하는 것이 최선이라는 데 동의합니다. 수천 개의 경고가 표시되는 경우 수정 우선 순위를 지정해야합니다.
컴파일러를 가장 낮은 경고 수준으로 설정하십시오. 이러한 경고가 가장 중요합니다. 이러한 문제가 해결되면 경고 수준을 높이고 가장 높은 경고 수준에 도달 할 때까지 반복하십시오. 그런 다음 경고가 오류로 처리되도록 컴파일 옵션을 설정하십시오.
무시해도 안전하다고 생각되는 경고를 발견하면 몇 가지 조사를 통해 이론을 확인하십시오. 그런 다음 가능한 가장 최소한의 방법으로 만 비활성화하십시오. 대부분의 컴파일러에는 #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 비트로 마이그레이션 할 계획이있는 경우 이러한 종류의 경고를 정리하기 만하면 포트 시간이 크게 단축됩니다.
코드에 경고를 남기거나 정리할 수없는 경우가 있습니다 (할 수있는 것은 제거하더라도). 예를 들면 :
- 작업중인 항목이 있고 더 많은 작업 /주의가 필요하다는 것을 알고있는 경우 적절한 경고를 표시하는 것이 적절할 수 있음을 표시합니다.
- / clr로 C ++를 컴파일하는 경우 네이티브 코드가 생성되는 원인에 대한 몇 가지 경고가 있습니다. 코드베이스를 기능적으로 변경할 수 없을 때 이러한 모든 경고를 억제하는 것은 번거로울 수 있습니다.
- 픽스의 기능을 이해하지 못할 때 경고를 정리합니다. PC-Lint 경고와 함께이 작업을 몇 번 수행했고 결국 버그가 발생했습니다. 변경의 정확한 효과가 무엇인지 모르는 경우 (예 : 경고를 제거하기위한 C 스타일 캐스트) 수행하지 마십시오. 경고를 알아 내거나 코드를 그대로 두는 것이 내 조언입니다.
어쨌든, 그것들은 경고를 남기는 것이 적절할 수있는 내 머리 꼭대기에서 벗어난 경우입니다.
최악의 부분은 새 코드를 작성할 때 실수로 더 많은 경고를 도입했는지 알기가 어렵다는 것입니다. 경고가 너무 많기 때문에 어쨌든 무시할 수 있기 때문입니다.
그것들을 모두 청소할 때의 문제는 시간이 걸리거나 없을 수도 있다는 것입니다. 그러나 예, 일반적으로 가능한 한 많이 정리해야합니다.
코드에 경고를 고칠 시간이 없기 때문에 경고를 남기는 것은 아침에 충분한 시간이 없기 때문에이를 닦지 않는 것과 같습니다. 코드 위생의 기본 문제입니다.
항상 경고를 정리하십시오. 경고가 괜찮다는 것을 알고있는 특정 사례가있는 경우 해당 인스턴스에 대해서만 표시하지 마십시오.
일부 경고는 무해 할 수 있지만 대부분은 코드의 실제 문제를 나타냅니다.
모든 경고를 정리하지 않으면 경고 목록이 계속 증가하고 경고 소음의 바다에서 실제 문제 사례가 손실됩니다.
정말 좋은 프로그래머의 특징 중 하나는 나쁜 코드가 배를 메스럽게 만든다는 것입니다.
나는 모든 코드를 컴파일러뿐만 아니라 IDE 내부에서 상당히 까다로운 수준으로 설정하기 위해 노력합니다. 도구보다 더 잘 알고 있다면 경고 인스턴스를 억제해야 할 때도 있지만 적어도 문서 역할도합니다.
항상 모든 경고를 활성화 한 다음 경고가 발생하면 빌드를 중지하도록 프로젝트를 설정합니다.
경고가있는 경우 각 경고를 확인하여 문제가 없는지 확인해야합니다. 이 작업을 반복하는 것은 시간 낭비입니다. 이렇게하지 않으면 코드에 오류가 발생하게됩니다.
경고를 제거하는 방법이 있습니다 (예 : #pragma argsused).
컴파일러가 작업을 수행하도록하십시오.
경고로 인해 불안정, 충돌 또는 메모리 손상이 발생하는 여러 임베디드 시스템과 함께 작업했습니다. 경고가 무해하다는 것을 알지 못한다면 처리해야합니다.
경고는 버그로 취급되어야합니다. 경고를 제거 할만큼 충분히 코딩 할 수 없다면 코딩을하지 말아야 할 것입니다. 우리 그룹에서는 모든 경고를 오류로 강제하기로 결정했습니다. 이 논의를 완전히 끝내고 IMHO는 코드 품질을 향상시킵니다.
나는 경고를 싫어한다. 가능한 한 많이 제거합니다.
때로는 일을 끝내라는 압력을 받으면 일부를 떠납니다. 나는 거의 떠나지 않는다. 남는게 있으면 더럽게 느껴져요.
내가 작업하는 코드베이스에는 4000 개가 넘는 경고가 있습니다. 그들 중 일부는 합법적 인 문제입니다. 우리는 들어가서 고칠 시간도없고, 다른 깨진 것들을 리팩토링 할 시간도 없습니다. 부분적으로 이것은 코드가 너무 오래되어 표준화 된 C ++보다 이전이기 때문입니다. VC ++ 6에서만 컴파일 할 수 있습니다.
Always clean up all warnings or explicitly suppress them if needed. The default settings for warnings should be highest possible when compiling (level 4 on VS for example).
My boss who created some code I now maintain. He uses compiler flags to hide his deprication warnings.
When I have time I go through and clean up what I can.
I try to compile code with a fairly high level of warnings and clean them all up, except for "signed / unsigned comparison" warnings, which I'm sure I should fix but can never be bothered.
Short version: In g++ I use "-Wextra -Wno-sign-compare" and get rid of all messages.
'code' 카테고리의 다른 글
| 다른 브랜치의 특정 커밋에서 브랜치를 만드는 방법 (0) | 2020.11.23 |
|---|---|
| 앱을 더욱 전문적으로 만드는 특징 / 기능? (0) | 2020.11.22 |
| array.xml에 색상을 저장하고 Color [] 배열로 되 돌리는 방법 (0) | 2020.11.22 |
| 텍스트 상자에 정수만 허용하는 방법은 무엇입니까? (0) | 2020.11.22 |
| 빌드 경로가 불완전하여 프로젝트가 빌드되지 않았습니다. (0) | 2020.11.22 |