C ++에서 인형을 피하는 10 가지 방법 - 인형

처음부터 C ++ 프로그램을 실제로 작성하는 것보다 버그를 검색하고 제거하는 데 더 많은 시간을 할애한다는 것은 불행한 사실입니다. 여기에 제시된 내용은 프로그래밍을보다 즐겁게 만들어주기 위해 프로그램에 도입 한 오류의 수를 최소화하는 데 도움이 될 수 있습니다.

모든 경고 및 오류 메시지 사용

C ++ 구문은 많은 오류 검사를 허용합니다. 컴파일러가 해독 할 수없는 구문을 발견하면 메시지를 출력 할 수밖에 없습니다. 소스 코드와 백업을 동기화하려고 시도하지만 (때로는 성공적이지 못함) 실행 파일을 생성하지 않습니다. 이렇게하면 프로그래머가 모든 오류 메시지를 수정해야합니다.

경고를 무시하거나 무시하는 것은 아주 나쁜 생각입니다. 그것이 당신을 괴롭히기 때문에 당신의 차 대쉬 보드에 "체크 엔진"표시 등을 뽑는 것과 같습니다. 문제를 무시한다고해서 문제가 해결되는 것은 아닙니다.

깨끗하고 깔끔하고 익숙한 스타일을 따르는 코드를 읽으면 C ++ 구문의 구문을 파싱하는 데 약간의 두뇌 능력을 소비합니다. 이것은 프로그램이하려고하는 것이 아니라 그것을하는 방법을 해독 할 수있는 뇌의 CPU 능력을 더 많이 남겨 둡니다.

클래스 이름, 객체 이름 및 함수 이름을 구별합니다.

클래스, 함수 또는 객체가 사용 된 것을 이해합니다.

좋은 코딩 스타일을 사용하면 다음을 쉽게 수행 할 수 있습니다. 이름에 따라

C + + 기호와 선행 프로세서 기호 구분 (#define 개체가 두드러 져야 함)

같은 수준의 C ++ 코드 블록 식별 (일관된 들여 쓰기의 결과 임)

또한 각 모듈의 기능이나 클래스, 작성자, 날짜, 버전 및 수정 내역에 대한 정보를 제공하는 모듈 헤더의 표준 형식을 설정해야합니다.
한 프로젝트에 참여하는 모든 프로그래머는 동일한 코딩 스타일을 사용해야합니다. 다른 코딩 스타일의 패치 워크로 작성된 프로그램은 혼란스럽고 전문가가 아닌 것처럼 보입니다.
코드를 작성하는 동안 코드 주석 작성
모든 것이 작동 될 때까지 기다린 후 주석으로 돌아가서 주석을 추가하는 대신 코드를 작성하는 동안 주석을 작성하면 오류를 피할 수 있습니다.

공식적인 의견은 당신이하려는 일을 재고 할 것을 강요합니다. 짧은 주석은 나중에 읽었을 때와 작성할 때 모두 깨닫게됩니다. 다른 프로그래머와 이야기하는 것처럼 주석을 작성하십시오.

디버거의 모든 경로를 한 번 이상 단일 단계로 실행

프로그래머는 프로그램이하는 일을 이해해야합니다. 프로그램이 예상 값을 출력하는 것으로는 충분하지 않습니다. 프로그램이하는 모든 것을 이해해야합니다.

싱글 스텝핑 () 프로그램보다 더 나은 느낌을주는 프로그램이 아니며, Code:: Blocks와 함께 제공되는 좋은 디버거를 사용하여 단계별로 실행합니다. 그 외에, 프로그램을 디버깅 할 때, 프로그램이 실행될 때 생길 수있는 기괴한 행동을 알아 내기 위해 원료가 필요합니다. 서비스가 시작될 때마다 각 기능을 단일 단계로 수행하는 것보다 재료를 더 잘 제공하는 것은 없습니다. 마지막으로, 기능이 완료되고 프로그램에 추가 될 준비가되면, 모든 논리 경로가 최소한 한 번 이동해야합니다. 버그는 함수의 나머지 부분과 함께 폿에 던져진 후에가 아니라 함수 자체를 검사 할 때 훨씬 쉽게 찾을 수 있습니다. 그러면 버그가 새로운 프로그래밍 문제로 옮겨 갔을 것입니다.

가시성 제한

클래스 내부의 가시성을 외부 세계로 제한하는 것은 객체 지향 프로그래밍의 초석입니다. 클래스가 내부 상태를 책임 져야합니다. 클래스에서 실수가 발생하면 클래스 프로그래머의 잘못입니다. 응용 프로그램 프로그래머는 문제를 해결하는 것에 대해 걱정해야합니다.

특히 제한된 가시성은 데이터 멤버가 클래스 외부로 액세스 할 수 없어야 함을 의미합니다. 즉, 데이터 멤버는 보호 대상으로 표시되어야합니다. 또한 응용 프로그램 소프트웨어가 알 필요가없는 구성원 기능도 보호 대상으로 표시해야합니다. 작업을 완료하는 데 필요한 것보다 더 많은 클래스 내부를 노출시키지 마십시오. 힙 메모리 추적 힙 메모리 손실 추적은 현장에 출시 된 프로그램에서 치명적인 오류의 가장 흔한 원인이며 동시에 추적하고 제거하는 것이 가장 어려운 문제입니다. 이 오류 클래스는 찾기 어렵고 제거하기가 쉽기 때문에 구매하는 프로그램에 널리 퍼져 있습니다. 메모리 누수 크기에 따라 문제가 발생하기 전에 몇 시간 동안 프로그램을 실행해야 할 수 있습니다.

일반적으로 프로그래머는 항상 힙 메모리를 동일한 수준으로 할당하고 해제해야합니다. "멤버 함수 MyClass:: create ()가 힙 메모리 블록을 할당하고 호출자에게 반환하면 힙에 반환하는 멤버 MyClass:: release ()가 있어야합니다.특히, MyClass:: create ()는 부모 함수가 메모리를 해제 할 필요가 없어야합니다.

가능한 한 MyClass가 자체적으로 이러한 메모리 포인터를 추적하고 소멸자에서 삭제해야합니다.

포인터를 지운 후에 포인터를 제로로 만듭니다.

포인터가 더 이상 유효하지 않게 된 후에 포인터를 제로로 만듭니다. 그들에게 nullptr 값을 할당함으로써 그렇게한다. 이 작업의 이유는 경험에 따라 분명 해집니다. 힙에 반환 된 메모리 블록을 계속 사용하고 알 수 없습니다. 프로그램이 99 %의 시간 동안 정상적으로 작동하므로 블록을 다시 할당하고 프로그램이 작동하지 않는 경우의 1 %를 찾는 것이 매우 어렵습니다.

더 이상 유효하지 않은 포인터를 null로 지정하고 값을 저장하기 위해 포인터를 사용할 경우 (널 위치 또는 그 근처에 아무 것도 저장할 수 없음) 즉시 프로그램이 중단됩니다. 충돌은 좋지 않지만 문제가 발생하는 경우는 아닙니다. 문제는 거기에있다. 생산에 투입하기 전에 발견했는지 아닌지에 대한 질문 일뿐입니다.

예외 처리를위한 예외 사용

C ++의 예외 메커니즘은 오류를 편리하고 효율적으로 처리하도록 설계되었습니다. 일반적으로 오류 플래그를 반환하는 대신 오류 표시기를 throw해야합니다. 결과 코드는 쓰기, 읽기 및 유지가 더 쉽습니다. 게다가, 다른 프로그래머가 그것을 기대하고 왔고, 당신은 그들을 실망시키고 싶지 않을 것입니다, 그렇지 않습니까?

예외 사용을 실제 오류로 제한하십시오. 이 함수의 일상 생활의 일부인 경우 "작동하지 않음"표시기를 반환하는 함수에서 예외를 throw 할 필요는 없습니다.

소멸자를 가상으로 선언하십시오.