D = A()->B()->C(); 이게 뭔 ㅈ ㄹ 이고?

변수명이야 종교와 문화라고 생각하면 넘어갈 수 있다.

아래처럼 함수의 리턴값을 막바로 caller로 사용하는건 이해할 수 없다.
A)
width = pObjManager->GetInstance()->CalcRect()->GetWidth();

 

난 무조건 다음과 같이 짜는데 이유가 디버깅 때문이다.
B)
pInstance = pObjManager->GetInstance();
pRect = pInstnace->CalcRect();
width = pRect->GetWidth();

 

A) 처럼 짜면 짤때야 편하겠지. 타이핑을 몇 자라도 줄일테니까.
근데 디버깅할때, 특히 코드 분석하려고 디버거로 따라가다보면 엄청 짜증난다. 중간값 확인하려면 함수 진입해서 리턴까지 따라가봐야 한다. F10/F11을 신경써서 선별적으로 눌러야 한다. 그러다가 STL컨테이너라도 만나면 브레이크 찍어서 탈출시켜야 한다. 함수호출부분까지 긁어다가 watch창에 드래그앤드롭 해보면 인라인 된 함수가 아니고선 당연히 값이 출력되지 않는다.

B) 처럼 짜면 F10만 눌러서 선형적으로 진행해도 중간값을 계속 확인할 수 있다. 당연히 변수를 watch창에 드래그앤드롭하면 값이 잘 나온다. 드래그앤드롭도 필요없이 변수에 마우스 커서만 올려놓으면 된다.

덤프 분석할때도 돌아버리는데 B)처럼 짰으면 어셈블리 코드상에서의 크래시한 위치가 C/C++소스코드상의 라인과 정확히 맞아떨어지지만 A)처럼 한줄에다 다 붙여버리면 소스코드 한줄이 여러개의 함수호출을 포함하고 있으므로 어느 함수에서 크래시했는지 알수가 없다.

기본적으로 어셈블리 코드와 C/C++코드 라인이 1:1 대응이어야 디버깅이 용이하다. 비슷한 이유로 템플릿도 싫어한다.

코드 라인 수만 줄이면 코드가 깔끔한거야?
프로젝트 전체 시간으로 따져보면 코드를 생산하는 시간보다 한줄 한줄 따라가며 디버깅하는 시간이 훨씬 길다.

‘의식의 흐름대로’ 두다다다다다 타이핑 하는 프로그래밍 문화를 나는 싫어한다.
이런 스타일은 빠른 속도로 코드를 생산해내지만 비례해서 버그를 양산한다. 대개 버그 신경 안쓰는 문화에서 이런 스타일이 유행한다.
그럴수도 있다고 생각은 한다. 말 그대로 죽으면 다시 실행하면 그만.
근데 ‘죽으면 다시 실행하면 그만’이 아닌 분야에선 어쩔껴.
저런 스타일이 힙한걸로 받아들여져서 정신 바짝 차리고 한줄 한줄 어떤 영향을 미칠지 고민해야하는 분야까지도 파고 드는건 문제다.


D = A()->B()->C(); 이게 뭔 ㅈ ㄹ 이고?”에 대한 답글 2개

  1. 지나가다 댓글 남깁니다
    저는 저렇게 쓰는걸 선호하고 JetBrains의 CLion, Rider 등으로 개발하는데

    pObjManager->GetInstance()->CalcRect()

    같은 문구를 통째로 watch에 때려박아도 잘 나와서 씁니다.
    요즘 IDE가 아주 좋아요~

    좋아요

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중