초보 프로그래머는 컴파일러 오류 용어가 부족하여 좌절했습니다.


66

저의 가족 친구가 (C 언어로) 프로그램을 배우면서 약간의 도움을 요청했습니다. 우리가 이야기하는 동안, 그는 자신의 컴파일러 (GCC)가 오류를 만들 때 그에게주는 오류 메시지를 이해하는데 어려움을 겪는 것에 대해 좌절감을 표현했습니다. 그는 사용 된 모든 용어를 이해하지 못하며 때로는 자신의 이해를 초월하는 조합입니다. 그는 "컴파일러 문서에 오류 메시지에 대한 자세한 설명이 포함되어 있지 않은 이유는 무엇입니까?" -나는 그에게 좋은 대답이 없었습니다.

저 자신보다 숙련 된 프로그래머로서이 상황에서는 매우 드물지만 그러한 드물게 발생합니다. 이전에는 경험하지 못한 이국적인 오류 메시지입니다. 나는 검색 엔진에서 오류 메시지를 찾는 데 성공했지만 분명히 그에게 항상 효과가있는 것은 아닙니다. 특히 그가 발견 한 오류가 더 흔하고 여러 가지 다른 경우에 발생하기 때문에 특히 개인적인.

그렇다면 초보자 프로그래머는 어떻게 컴파일러 오류 메시지를 이해해야 하는가? 구체적으로 C와 GCC의 조합으로?


7
"초보 프로그래머는 어떻게 컴파일러 오류 메시지를 이해해야 하는가?" / sarcasm 필요한 첫 번째 기술은 컨텍스트와 관련된 내용을 포함하여 컴파일러 메시지에서 모든 비트를 읽을 수 있어야합니다. / sarcasm off. 컴파일러의 결함이나 버그로 판명되는 경우는 거의 없습니다.
πάντα ῥεῖ

10
@MasonWheeler : 초보자는 종종 훈련을받을 때 사용할 컴파일러를 선택하지 않습니다. 그리고 GCC는 많은 시스템의 공통 분모입니다.
einpoklum

24
GCC C ++ 템플릿 오류와 관련하여 "오류 <file : line>"이후에 읽기를 중지하고 소스 파일을 연구하면 오류를 더 빨리 발견 할 수 있습니다. 내가 GCC에 의해 주어진 실제 오류를 읽는다면 .....
mattnz

18
해결책은 분명합니다. 혼동이 적은 출력을 가진 컴파일러를 사용하십시오. 나는 rmcc를 제안 한다 . 코드가 컴파일되었는지 여부에 따라 인쇄 Yes.되거나 인쇄 No.됩니다. 길고 무의미한 메시지를 이해하지 못하는 것에서 좌절감을 즉시 제거합니다!
파이프

21
C는 초보자에게는 좋은 언어가 아니며, 그 이유 중 하나를 발견했습니다. 그러나 Clang은 초보자에게 더 매력적인 오류를 제공하는 경향이 있습니다.
Theodoros Chatzigiannakis

답변:


164

몇 가지 유용한 기술 :

  • -Wall및을 켭니다 -Werror. 더 많은 오류 메시지를 작성하기 위해 오류 메시지를 해독하는 데 어려움을 겪는 경우 반 직관적 인 것처럼 보일 수 있지만 일반적으로 경고를 이해하고 문제의 실제 원인에 더 가깝게 경고를 이해하면 이해하기 어려운 오류가 발생할 수 있습니다. .
  • 목록에서 첫 번째 오류를 수정하십시오. 종종 오류가 서로 합성되어 나중에 오류 메시지가 실제로 실제 오류가 아닙니다. 하나를 수정하고 다시 컴파일하십시오. 경험이 많을수록 여러 개의 오류 메시지를 수정하는 데 도움이됩니다.
  • 최신 컴파일러 버전을 사용하십시오. C는 매우 안정적인 언어입니다. 따라서 최신 컴파일러에서 개선 된 부분은 언어 기능을 추가하는 것이 아니라 더 나은 오류 메시지를 포함하여 개발자 환경을 개선하는 것입니다. 대부분의 널리 사용되는 리눅스 배포판이 매우 기본적으로 GCC의 이전 버전을.
  • 점진적으로 프로그램하십시오. 컴파일하기 전에 많은 코드를 작성하려고 시도하지 마십시오. 여전히 컴파일 할 수있는 가장 짧은 양을 쓰십시오. 마지막으로 깔끔하게 컴파일 한 후 한 줄만 변경 한 경우 실제 문제가있는 줄을 알아내는 것이 훨씬 쉽습니다.
  • 단위 테스트를 작성하십시오. 컴파일 오류를 수정할 때 리팩토링 변경 사항을 명확히 할 수 있습니다.

23
좋은 IDE는 또한 예를 들어 경험을 크게 도울 수 있습니다. 빨간색으로 밑줄을 긋습니다.
BlueRaja-대니 Pflughoeft

86
"증분 적으로 프로그램하십시오. 컴파일하기 전에 많은 양의 코드를 작성하려고하지 마십시오. 여전히 컴파일 할 수있는 가장 짧은 양을 작성하십시오. 마지막으로 깨끗하게 컴파일 된 이후 한 줄만 변경 한 경우 알아내는 것이 훨씬 쉽습니다. 어떤 줄에 실제 문제가 있는지 " 이건 너무 많아 또한 컴파일하지 않는 코드를 작성하고 오류를 강조 표시하면 대부분의 IDE에서 경고합니다.
Polygnome

4
@einpoklum : 세 번째 옵션을 과소 평가하지 마십시오. 컴파일러 오류 메시지가 많이 향상되었습니다. 비슷한 맥락에서 여러 컴파일러 (예 : gcc 및 clang)를 사용하십시오. 더 많은 오류 / 경고를 포착하면 그 중 하나가 특정 문제에 대해 다른 진단보다 나은 진단을받을 수 있습니다.
Mat

19
@einpoklum : 좀 더 점진적으로 글을 쓰는 것은 특히 초보자에게 매우 중요합니다. "짧은 프로그래밍 할당"을 점진적으로 수행 할 수 없다고 생각하는 경우,이를 여러 개의 작은 함수로 나누고 하나씩 구현하고 컴파일하면 그 기술을 직접 향상시켜야합니다.
Doc Brown

4
나를 도운 트릭 : 오류 메시지에 N 줄이 언급되면 N-1 줄을 확인하십시오. 예를 들어, 17 행에서 세미콜론이 누락 된 경우 오류 메시지에 18 행에 문제가 있다고 표시됩니다. 이는 컴파일러가 세미콜론을 예상했지만 다음 행에서 다른 것을 얻었 기 때문입니다.
user2023861

56

친구는 용어집이 필요하지 않습니다. 용어집은 그를 도울 수 없습니다. 그가 필요로하는 것은 컴파일러 오류가 발생할 때해야 할 일에 대한 더 나은 직관입니다.

C 컴파일러 오류는 C # 컴파일러 오류와 같이 직관적이지 않습니다. 많은 이유로 C의 "금속에 근접한"특성과 관련이 있습니다. C에서 컴파일러 오류를 해결하는 것은 패턴 일치 연습이 아닙니다. receive는 실제 문제와 아무 관련이 없습니다. 오류 메시지가 일반적으로 정확한 코드 위치 및 문제에 매핑되는 C # 또는 Java와 달리 C의 오류는 많고 멀리 있습니다.

이에 대한 예는 "세미콜론 예상"또는 파서가 무언가 (반드시 세미콜론 일 필요는 없음)에 걸린 것을 나타내는 많은 구문 오류입니다. 또는 "예기치 않은 사전 선언"과 같은 오류입니다. 오류는 .h 파일 중 하나에서 대문자를 잘못 사용했음을 의미하지만 .h 파일을 문제의 원인으로 가리키는 것은 아닙니다.

친구의 전략은 이것을 오류 및 솔루션 목록과 일치시키는 것이어서는 안됩니다. 실제 문제가 무엇인지 파악할 수있을 정도로 C 언어의 구문과 사양을 잘 이해해야합니다 .


17
아니요. 숫자 식에 대입 할 수없고 변수에만 대입 할 수 있다는 것을 알기에 충분히 언어를 아는 것이 좋습니다. lvalue가 무엇인지 전혀 알 필요가 없으므로 초보자 과정에서 가르치지 않습니다.
Robert Harvey

18
본질적으로 그렇습니다. 그러나 실제로는 불가능합니다. 나는 이것을 오랫동안 오랫동안 해왔고 C 프로그램을 작성할 때마다 여전히 컴파일러 오류 메시지가 흐려집니다. 그러나 나는 그 메시지를 읽고 이해하려고 노력하는 경우가 거의 없다. 대신 오류 메시지가 가리키는 위치를 살펴보고 C 프로그램의 기본 구문 구조가 어떻게 보이는지 알고 있기 때문에 오류 메시지를 해독하는 데 시간을 소비하지 않고 비교적 빨리 문제를 발견 할 수 있습니다.
Robert Harvey

36
다시 말해, 컴파일러 오류를 이해하기위한 용어집을 요구하는 것은 영어를 이해하기 위해 사전을 읽는 것과 약간 비슷합니다. 그것은 그것이 작동하는 방식이 아닙니다. 사전을 읽지 않고 영어를 읽고 쓰면서 영어를 배우고 이해합니다.
Robert Harvey

14
[shrug] 이미 존재하는 영어 지식을 보충 하기 위해 사전을 사용하지 않는다면 , 잘못하고있는 것이 좋습니다. 마지막으로 제안하는 것은 초보자 프로그래머가 어휘에 더 이상 익숙하지 않게하는 것입니다. 프로그래머는 더 많은 단어가 필요하지 않습니다. 그들은 더 많은 기술이
Robert Harvey

13
@einpoklum, 용어집은 여기서 도움이되지 않습니다. 'lvalue'라는 단어에 대한 설명은 초보자에게는 너무 기술적 인 것이거나 도움이되지 않는 '할당의 왼쪽에있을 수있는 것'의 선을 따라있을 가능성이 높습니다.
Bart van Ingen Schenau

26

언급 할 가치가있는 관련 기술은 두 번째 컴파일러를 사용하는 것입니다. 예를 들어 Clang은 더 나은 오류 메시지에 투자했지만 오류를 표현하는 다른 방법은 깨달을 수 있습니다.

이것은 특히 가장 복잡한 유형의 오류에 해당됩니다. 예를 들어, 초보자에게 드문 일이 아닌 두 개의 유사한 구성을 혼합하면 컴파일러는 일반적으로 올바른 오류 메시지를 생성하는 데 문제가 있습니다. 컴파일러가 실제로 구문 B를 계획했을 때 구문 A의 잘못된 사용법에 대한 오류 메시지를 표시하면 혼동을 일으킬 수 있습니다. 두 번째 컴파일러는 의도 한 B를 유추 할 수 있습니다.


13

누군가가 얼마 전에 Wikibooks에서 GCC 오류 용어를 시도 했지만 결코 이륙하지 않았고 업데이트되지 않은 것처럼 보입니다.

"오류"섹션은 "경고"섹션보다 훨씬 더 나옵니다. G ++을 목표로 한 것처럼 보이지만 여전히 친구에게 유용한 정보가있을 수 있습니다.


12

위의 답변 외에도 대부분의 컴파일러 에는 포괄적 인 오류 용어 가 없습니다 . 메시지 자체가 자주 변경되므로 유지 관리해야 할 작업이 많으며 많은 것들이 있습니다.

용어집을 대체하는 가장 좋은 방법은 인터넷에 대한 액세스입니다. 컴파일러가 이해하지 못하는 오류를 생성 할 때마다 가장 먼저 오류가 발생하여 혼동 될 가능성이 거의 없습니다. 정확한 메시지에 대한 빠른 Google은 종종 읽기 쉬운 형식으로 많은 정보를 제공하기에 충분하며, 종종 자신과 매우 유사한 예제 코드가 있습니다.

그 외에도 언어와 컴파일러에 대한 시간과 친숙 함 만 있으면됩니다. 그, 그리고 칼 Bielefeldt에 의해 주어진 좋은 조언 .


1
나는 그것이 유지 해야 할 많은 일 이라고 생각하지 않습니다 . 또한 신뢰할 수있는 사람들에게 편집자 권한을 부여하여 Stackoverflow 또는 Wiki와 같은 대중이 추가 할 수 있습니다.
einpoklum 8:19에

6
@einpoklum PHP 문서를 본 적이 있습니까? 그것이 지역 사회가 그 일을 처리하게 할 때 일어나는 일입니다.
Kevin

4
옛날 옛적에, 출판 된 (인쇄 된) 매뉴얼 만이 사용 가능한 유일한 자원이었습니다. 일반적으로 문제를 해결하는 데 필요한 정보 / 지침을 제공하기 위해 충분히 작성되었습니다. 인터넷의 진화로 아무도 더 이상 출판물을 출판하지 않습니다 (물론 온라인이라면). "공식적인"참조 자료의 품질 (온라인 또는 기타)은 제가 프로그래밍해온 수십 년 동안 상당히 떨어 졌으므로 가능한 최상의 리소스는 종종 Google이며 가장 유용한 결과는 종종 Stackoverflow에서 나타납니다.
Zenilogix

2
용어집 존재 하더라도 검색 엔진이 가장 적합한 방법 일 수 있습니다. 그들은 또한 당신이 미지의 영역에있을 때 발견하는데 유용하다 : 유일한 검색 결과가 에러 메시지를 정의하는 소스 코드
Warbo

2
대학에서 한때 컴파일러 오류 "Dave는 이런 일이 발생하지 않는다고 생각합니다. <dave@example.com>으로 이메일을 보내주십시오." 나는 그에게 이메일을 보냈고 사실 나는 그 특정 오류를 가장 먼저 맞았습니다!
user1118321

6

C 표준은 다른 프로그래밍 언어와 다른 방식으로 "lvalue"및 "object"와 같은 여러 용어를 사용하며 컴파일러 메시지는 종종 이러한 용어로 작성됩니다. 용어의 사용은 본 표준의 일부에서 일관성이 없지만, C를 배우고 자하는 사람은 C89, C99 및 / 또는 C11 표준의 초안과 이에 대한 근거 문서를 살펴 봐야합니다. "C99 초안"또는 "C89 이론적 근거"와 같은 검색은 꽤 잘 작동하지만 예상 한 문서를 확보해야 할 수도 있습니다. 대부분의 컴파일러는 C99 표준을 지원하지만 C89 표준과 어떻게 다른지 아는 것이 유용 할 수 있으며 C89 이론적 근거는 이후 버전에서는 그렇지 않은 역사적 배경을 제공 할 수 있습니다.


11
C 표준은 매우 조밀하고 무거운 텍스트입니다. 초보자는 그것을 이해할 기회가 없습니다.
NieDzejkob

4
@NieDzejkob : 컴파일러가 사용하는 용어 (질문과 관련이있는 것 같음)는 표준에서 파생되었습니다. 표준의 일부는 이해할 수없는 것이 맞지만 (일부는위원회가 설계하고 저자가 어떤 부분이 의미하는지에 대한 일관된 이해를 갖고 있지 않은 것 같지만) 무엇을 이해하고자하는 사람은 "lvalue"와 같은 용어는 그들이 어디에서 왔는지 알아야합니다. 또한 왜 x=0x1e-x오류가 발생 하는지 이해하고 싶다면 표준 이외의 다른 것을 전혀 모른다.
supercat

3
@NieDzejkob에 동의합니다. C 표준은 초보자와 맞서고 싶은 텍스트가 아닙니다. 초보자에게는 빠른 실습 경험이 필요합니다 . 그리고 그들은 팝업으로 새로운 것을 하나씩 배워야합니다. 표준 또는 이론적 근거를 읽는 데는 시간이 많이 걸리며 초보자에게 정보를 완전히 과부하시킵니다.
cmaster

2
@ cmaster : 나는 오래 전 C89 Standard로 시작했으며 편리한 '찾기 텍스트'기능을 갖춘 브라우저 이전에도 그렇게 나쁘지 않았습니다. 나는 나중의 표준이 점점 더 나빠 졌다는 것을 인정할 것이다. 아무도 표준을 단독 참조로 사용해서는 안되지만, 마이크로 컴퓨터 컴파일러의 작동 방식과 표준이 저품질의 동작을 허용하는 방식에 대한 민중의 차이를 인식하는 것이 중요합니다. 후자를 다루기 위해.
supercat

3
@cmaster : 어쨌든 C를 프로그래밍하는 사람은 표준을 알고 있어야하며 전체 내용을 읽으려고하지 않더라도 필요할 때이를 참조하는 방법을 알아야합니다. 예를 들어, 표준 라이브러리 함수에 대한 웹 검색을 수행하는 경우 표준의 관점에서 해당 코너 케이스가 정의되지 않은 동작을 호출하고 다른 구현은 같은 방식으로 작동하지 않습니다. 대신 표준을 검색하면 해당 문제를 피할 수 있습니다.
supercat

5

아무도 명백한 대답을하지 않았으며 실제로 가장 자주 사용되는 것으로 의심됩니다. 오류 메시지를 읽지 마십시오.

대부분의 오류 메시지의 가치의 대부분은 단순히 그와 같은 줄에 문제가 있다는 것입니다. 대부분의 경우 줄 번호를보고 해당 줄로 이동합니다. 그 시점의 오류 메시지에 대한 나의 "읽기"는 일반적으로 탈지가 아니라 내 눈이 지나가는 것입니다. 회선에서 또는 근처에서 무엇이 잘못되었는지 즉시 명확하지 않으면 실제로 메시지를 읽습니다. 이 워크 플로우는 오류나 오류를 강조하는 IDE 또는 툴링을 사용하는 것이 훨씬 좋으며, 작은 변화 만 고려하는 Karl Bielefeldt의 제안을 자동으로 수행합니다.

물론 오류 메시지가 항상 적절한 줄을 가리키는 것은 아니지만 종종 적절한 근본 원인을 가리 키지 않기 때문에 오류 메시지를 완전히 이해하더라도 도움이되지 않습니다. 적절한 회선을 찾는 데있어 어떤 오류 메시지가 더 안정적인지에 대한 아이디어를 얻는 데 시간이 오래 걸리지 않습니다.

한편으로, 초보자가 만들 수있는 대부분의 오류 는 컴파일러의 도움 없이도 숙련 된 프로그래머에게 고통 스럽습니다 . 반면에, 그들은 초보자에게 너무 명확하지 않을 것입니다 (많은 사람들이 명백 할지라도 대부분의 실수는 바보 같은 실수입니다). 이 시점에서 나는 Robert Harvey에 전적으로 동의한다. 초보자는 단순히 언어에 더 익숙해 져야한다. 이것을 피할 수는 없습니다. 익숙하지 않은 개념을 참조하거나 놀라운 것처럼 보이는 컴파일러 오류는 언어에 대한 지식을 심화시키기위한 프롬프트로 보여야합니다. 컴파일러가 불평하지만 코드가 왜 틀린지 알 수없는 경우에도 마찬가지입니다.

다시 한 번 컴파일러 오류를 활용하기위한 더 나은 전략이 필요하다는 Robert Harvey에 동의합니다. 위의 몇 가지 측면을 설명했으며 Robert Harvey의 답변은 다른 측면을 제공합니다. 친구가 그러한 "용어집"으로 무엇을하기를 원하는지는 명확하지 않으며, 그러한 "용어집"이 실제로 친구에게 큰 도움이되지 않을 것입니다. 컴파일러 메시지는 확실히 언어 1 의 개념을 소개하는 장소 가 아니며 "용어집"은 그다지 나은 곳이 아닙니다. 오류 메시지의 의미를 명확하게 설명하더라도 문제 를 해결 하는 방법을 알려주지는 않습니다 .

1 Elm 및 Dhall (및 아마도 라켓)과 같은 몇 가지 언어와 "초보자 중심"언어 구현은이 작업을 시도합니다. 이러한 맥락에서, 다른 구현을 사용하려는 MSalters의 조언은 직접적인 관련이 있습니다. 나는 개인적으로 그런 것들을 타협하지 않으며 올바른 문제를 목표로하지 않습니다. 이것은 더 나은 오류 메시지를 만드는 방법이 없다는 것을 말하는 것이 아니라 나에게 컴파일러의 신념과 그 신념의 기초를 더 명확하게 만드는 데 중점을 둡니다.


4

그렇다면 초보자 프로그래머는 어떻게 컴파일러 오류 메시지를 이해해야 하는가? 구체적으로 C와 GCC의 조합으로?

이해하지 못하는 오류가 발생하면 친구에게 다음을 수행하도록 지시하십시오.

  • 마지막으로 성공한 빌드 이후 추가 된 코드를 제거하거나 주석 처리하십시오.
  • 그것의 작은 부분을 다시 넣고 컴파일
  • 오류가 발생할 때까지 반복하십시오

컴파일러 오류는 컴파일러가 코드에 대해 이해하지 못하는 내용 만 알려주고 잘못된 것은 아닙니다. 이 접근법은 오류를 인터넷 검색하고 일부 문서 또는 StackOverflow 게시물을 읽는 것과 거의 같은 시간이 걸리지 만 잘못하고있는 것이 무엇인지 이해하는 데 훨씬 도움이됩니다.

또한 빌드하는 데 몇 분이 걸리는 프로젝트에서 작업을 시작할 때까지 자주 컴파일하도록하여 너무 많은 다른 코드를 추가하기 전에 오류를 발견하면 많은 도움이됩니다.

마지막으로 한 번에 한 가지 작업을 수행하고 사이에서 컴파일하지 않고 여러 파일에서 작업하지 말고 한 번에 여러 종속성을 도입하지 마십시오.


4

다른 기술은 친구가 다른 오류 메시지가 표시 될 때 시간이 지남에 따라 자신의 용어집을 작성하는 것입니다. 무언가를 배우는 가장 좋은 방법은 종종 그것을 가르치는 것입니다. 물론, 용어집이 완성 될 때까지 그는 더 이상 필요하지 않을 것입니다.

GCC에 대한 개인적 경험은 각 오류 메시지가 "일반적인"실수와 관련이 있다는 것입니다. 예를 들어 GCC가 "&를 잊어 버렸습니까?"라고 말하면 일반적으로 괄호를 잊어 버린 것입니다. 물론, 어떤 실수가 어떤 오류 메시지에 해당하는지는 프로그래머에 따라 달라지며, 친구가 자신의 용어집을 작성하는 또 다른 이유입니다.


1
이 문서는 온라인으로 제출할 수 있고 (5-10 개 항목 만 포함되어 있어도) 인턴쉽을 신청할 때 큰 차별화 요소가 될 수있는 매우 중요한 부수적 인 이점이 있습니다.
Josh Rumbut
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.