다른 사람의 소스 코드 해석하기

참고 : 이 질문에 대해 알고 있습니다. 이 질문은 좀 더 구체적이고 심층적이지만, 실제 코드를 디버깅하거나 저자에게 묻는 것이 아니라 실제 코드를 읽는 데 중점을 둡니다.

입문 수준의 컴퓨터 과학 수업을 듣는 학생 인 친구들은 가끔 과제를 도와달라고 부탁합니다. 프로그래밍은 제가 자랑스럽게 생각하는 것이므로 항상 기뻐합니다. 그러나 일반적으로 소스 코드를 해석하는 데 어려움이 있습니다.

때때로 이것은 이상하거나 일관되지 않은 스타일 때문일 수 있으며, 때로는 과제에 지정된 이상한 디자인 요구 사항 때문일 수도 있고 때로는 내 어리 석음 때문일 ​​수도 있습니다. 어쨌든, 나는 몇 분 동안 화면을 응시하는 바보처럼 "어 ..."

일반적으로 추출기 연산자 대신 쉼표를 사용하여 세미콜론이나 괄호가없는 일반적인 오류를 먼저 확인합니다.

그것이 실패하면 문제가옵니다. 구문 오류이기 때문에 종종 디버거를 사용하여 단계를 수행 할 수 없으며 저자가 디자인 결정을 이해하지 못하기 때문에 저자에게 종종 요청할 수 없습니다.

일반적으로 다른 사람의 소스 코드를 어떻게 읽습니까? 위에서 아래로 코드를 읽거나 호출 될 때 각 함수를 따르나요? "리팩터링 할 시간"이라고 말할 때를 어떻게 알 수 있습니까?

첫 번째 팁 : IDE (또는 매우 훌륭한 편집기)를 사용하여 구문 오류, 잘못 배치 된 괄호 및 기타 사소한 실수를 발견하십시오.

두 번째 단계 : 모든 코드를 편한 형식으로 자동 형식화하십시오. 이것이 중요하지는 않지만 놀랍게도 그렇게 생각합니다.

이름이 잘못 지정된 로컬 변수의 이름을 바꾸는 것을 두려워하지 마십시오. (전체 시스템에 액세스 할 수 있으면 이름을 바꿀 수 있으므로해야합니다.)

특정 기능 / 방법이 수행중인 작업을 발견하면 자신에게 의견을 추가하십시오.

인내심을 가지십시오. 외계인 코드를 이해하는 것은 쉽지 않지만 대부분의 퍼즐 조각이 갑자기 제자리에 들어가는 획기적인 순간이 있습니다. 그 시점까지는 모두 힘든 일이며 혼란입니다. 좋은 소식은 실제로 유레카의 순간이 더 빨리 올 것이라는 점입니다.

나는 당신이 이것에 대해 잘못된 접근법을 취하는 것 같아요. 사람들이 자신의 코드에 대한 도움을 받기 위해 당신에게 의존하고 있다면, 나는 당신이 돌아 서서 코드를 안내하도록 할 책임이 있다고 생각합니다. 오류를 고칠 수 있고, 자신의 오류 (도움이있는)를 발견하면 더 많이 배울 가능성이있는 경우 무언가를 배울 수 있습니다 (무리). 또한 다른 사람들이 코딩에 접근하는 방법에 대한 더 넓은 경험을 얻을 수 있습니다 (더 많은 코드를 읽고 이해할 수있게 해줍니다)-선순환 ... ...)

나는이 능력이 혼합 된 경험이며 단지 재능이 있다고 생각합니다. 우리는 처음부터 무언가를 만들도록 요청하면 더 많거나 적은 것을 해결할 수있는 직원이 있었으며 동시에 작성하지 않은 코드 조각에서 명백한 버그를 완전히 찾을 수는 없었습니다. 또한 동시에 기본 디자인을 능가하는 것으로는 믿지 않지만 다른 사람에게 직접 코드를 작성하여 문제를 추적 할 수있는 직원을 확보했습니다.

즉, 이에 접근하는 방법은 코드를 변경하는 것입니다. 익숙한 것으로 형식을 변경하고 변수 이름을 자신에게 적합한 것으로 변경하고 코드가 명확하지 않은 경우 주석을 추가하십시오. 그가 도움을 요청했다면 문제를 발견 할 때까지 계속 진행해야합니다. 그런 다음 원래 코드를 수정하거나 사용하는지 친구에게 맡기십시오.

먼저 구문 오류가있는 경우 컴파일러 오류를주의해서 읽어야합니다. 종종 행이 오류로 강조 표시되지만 실제로 오류가 발생한 이전 행 이었습니다 .

입문 학생에게는 프로그램을 볼 수없는 편집 인공물이있을 수 있습니다. 예를 들어, 나는 스페이스 바를 리턴 대신에 사용하는 학생 (나의 것이 아닌)을 보았습니다. 그의 코드는 80 열을 감싼 편집기에서 정상적으로 보였으며 (학생은 매우 참을성이있었습니다), 코드는 추가 될 때까지 작동했습니다. " //"스타일 주석, 나머지 프로그램 전부 주석 처리. 마찬가지로 웹 사이트에서 코드 샘플을 복사하는 경우 웹 사이트의 코드 형식에 따라 인쇄 할 수없는 문자도 종종 복사됩니다. 확실치 않은 경우 복사하여 붙여 넣지 않고 줄을 다시 입력하십시오. [놀랍지 만 최근에 더 많이 발생하는 것을 보았습니다.]

불쾌한 컴파일러 오류의 경우 새 파일을 만들고 진행하는 동안 모든 코드를 입력하여 프로그램을 확장해야 할 수도 있습니다. 다음 단계로 넘어 가기 전에 각 주요 단계 후에 컴파일해야합니다.

그렇다면 구문 오류가없는 경우는 어떻습니까? 그런 다음 코드를 살펴볼 차례입니다! 이를 위해 디버거를 사용할 수 있지만 printf코드 전체 를 호출하는 것도 매우 효과적입니다. 예를 들어, for루프 가있는 경우 루프 카운터에 대한 print 문을 추가하십시오. 중첩 for루프 의 경우 잘못된 변수가 증가하고 있음을 알 수 있습니다.

printfs 사용 의 장점 은 현재보고있는 시간 / 공간에 따라 "압축"할 수 있다는 것입니다. 디버거를 단계별로 실행하면 관련성이없는 상태가 많으며 더 지루할 수 있습니다. 또한 콘솔에 인쇄 된 내역을 보지 않으면 일부 패턴이 누락 될 수 있습니다. 여기서 요점은 디버거와 printfs가 상호 보완적인 기술이며 항상 다른 것보다 낫다는 것입니다.

마지막으로, 친구에게 무슨 일이 일어나고 있는지 물어보십시오! 그것을보고 "uh"라고 말하지 말고 그들이 무엇을하고 있는지 물어보십시오. "지금 무엇을 n합니까?" 대화 상자를 시작하면 자신의 질문에 대한 답을 얻거나 프로그램에 결함이 있음을 개념화 한 방식을 알게되어 솔루션으로 이어질 수 있습니다.

다른 곳에서 언급 했듯이이 모든 것이 경험이 향상됩니다. 20 년 동안 프로그래밍을 해왔지만 지난 5 년간 학생과 함께 일하면서 오류를 해결하는 데 더 도움이되었습니다.

나는 이것을 말하기 싫어하지만 여기에은 총알이 없습니다.

솔직히 다른 사람들 이 10 %의 사례를 썼을 때 다른 사람들이 무엇을 의미 했는지 이해할 수있을만큼 솔직 해 졌다면 , 지금까지 수백만의 사람들이 의심 할 여지가 없을 것입니다.

보다 실용적인 메모에서 지능형 IDE를 사용하는 것은 1 단계입니다.

2 단계 는 소스 코드 계층을 파악 하기 위해 doxygen 또는 이와 유사한 것을 실행하는 것 입니다.

3 단계는 앵커 기능 또는 객체, 명령 행 또는 파일을 처리 한 다음 논리를 수행하는 것을 찾는 것입니다.

3 단계와 병행하여 글로벌을 사용중인 경우이를 추적하십시오. 동료에게 알려진 특정 알고리즘을 사용 중인지 물어보십시오. 코드를보기 전에 알고리즘을 읽는 것이 좋습니다 (있는 경우).

한 마디로, 경험 : 경험이 많을수록 모범 사례를 더 많이 배우고 다른 사람들의 코드를 판단 / 이해할 수 있습니다. 그것은 자동적으로 오지 않으며, 대신 종종 같은 실수를해서 만 나옵니다!

즉, 코드를 볼 때 종종 코드에서 외삽하기가 매우 어려운 주요 사고 과정의 결과 일 뿐이므로 프로그래머가 코드에 대한 올바른 주석을 달아야합니다. 몇 가지 의견, 디자인 생각을 가진 텍스트 파일은 코드 이해와 완전히 오해하는 데 차이를 만들 수 있습니다.

나는 종종 학교 실험실에서 같은 질문을 받았습니다. 일반적으로 질문은 "이 컴파일러 오류를 어떻게 해결합니까?"로 시작했습니다. 그래서 매달려있는 else세미콜론 등 을 발견하는 데 능숙했습니다 . (매크로도 디버그하기가 즐겁습니다. #define CUBE(x) x * x * x우리 모두가 저지르는 실수입니다.) 제가 가진 장점은 같은 선생님들과 같은 수업을 겪었 기 때문에 이미 요구 사항에 익숙했습니다.

내가 가장 잘 작동하는 프로세스는 실행중인 대화 상자를 유지하는 것입니다. 그들이 배울 필요가 있기 때문에 프로그램을 작성하고 싶지 않습니다. 이것은 당신이 그들과 같은 컴퓨터에 있어야 함을 의미합니다. 실험실에서 나는 그들의 컴퓨터에 올 것이다. 컴파일러 메시지로 시작하여 오류를 발견하려고합니다. (C를 사용하고있었습니다.) 줄 번호로 시작하고 메시지와 오류가 해당하는 위치를 가리 킵니다. 동일한 오류가 두 개 이상인 경우 두 오류에 대해 비슷한 것이 무엇인지 물어볼 것입니다.

전체 아이디어는 다른 학생을 안내하는 것입니다. 코드를 다시 작성해도 학습에 도움이되지 않습니다.

구문 오류는 논리 오류보다 찾기가 훨씬 쉽습니다. 대부분의 문제가 구문 인 경우 IDE를 찾고 코드를 복사하여 붙여넣고 오류를 수정하십시오. 논리 오류는 훨씬 더 어렵습니다. 왜 당신이 그들의 코드를 설명하도록 요청할 수 없다고 말했는지 잘 모르겠습니다. 다른 사람에게 코드를 설명하여 많은 논리 오류를 발견했습니다.