Media Log

프로그램을 처음 배울 때는 거의 정신병자 수준으로 코딩 스타일에 집착했었는데 나이가 들어가면서 코딩 스타일에 조금씩 둔감해져가고 있다.
대학 때는 들여쓰기를 tab으로 했었는데 첫번째 회사에서 space가 규칙이라고 꼭 그렇게 쓰라고 강제했다. 나는 tab을 버리기 싫었지만 규칙을 어기지 않기위해 그렇게 쓰다보니 space가 너무 좋아져버렸다. 2번째 회사에서는 다시 tab을 사용하라고 한다. 좀 촌스럽네? 아직도 tab을 쓰는데가 있었나 정도의 생각은 들지만 거부감 없이 받아들일 수 있었다. 그 외의 다른 스타일들도 비슷하다.

그래도 여전히 눈에 거슬리고 바꿔버리고 싶은 욕구가 드는 C/C++ 코딩 스타일이 2가지가 있는데 그 중 하나는
if (0 == str.Length())
{
}
위처럼 상수를 좌측에 쓰는 코드이다.
프로그램을 읽기에도 불편하고 쓸 때 또한 불편한데 도대체 왜 상수를 왼쪽에 쓰는가.

아마 어떤 사람들은 그렇게 써야 == 연산자 대신 = 를 사용해버리는 실수를 방지할 수 있어요, 라고 대답할지도 모른다. 하지만 요즘 컴파일러는 이런 실수를 경고로 가르쳐주는 기능을 다 가지고 있는데 굳이 저렇게 쓸 필요가 있는가? 컴파일러나 정적분석툴의 도움를 받을 수 없는 상황에서나 어쩔수 없이 사용하던 구식 방법인데 이를 무작정 따라하는 사람들이 많다. 다음 코드는 조금 더 보기에 안좋다.
if (MAX_PATH <= str.Length())
{
}
'상수를 왼쪽에 써야 실수를 줄일수 있다고 했지'. 라고 생각없이 이 말을 받아들인 사람들은 == 이 아니라 비교연산자를 사용할 때에도 모든 상수는 죄다 왼쪽에 써버린다. 위 코드를 읽을 때 머리가 2번씩 돌아가는 것 같지 않은가?

또 한가지 싫어하는 C/C++ 스타일은
bool xxx = fOk;
if (xxx == true)
{
}
이렇게 불린 테스트를 true나 false와 명시적으로 비교하는 것이다.

아래 strcmp 함수의 경우 처럼 표현식의 결과가 불린 값이 아닌 경우에는(strcmp의 리턴값은 정수이다) 같은 타입으로 명시적으로 비교를 해서 표현식을 참 혹은 거짓으로 맞추어 주는 것이 의미가 있다.
if (!strcmp(xxx, yyy)) // 이보다는
if (strcmp(xxx, yyy) == 0) // 이게 더 낫다고 생각한다.
하지만 이미 어떤 변수나 식이 이미 참과 거짓을 나타내고 있다면 또 다시 그것을 true나 false와 비교하는 것은 명백한 중복이다. 나는 그런 경우는 그냥
if (xxx)
{
}

또는
if (!xxx)
{
}
이렇게 쓰는 것을 선호한다.

위에서 처럼 true와 비교하는 것보다 1로 정의된 대문자 TRUE를 비교하는 것은 훨씬 나쁘다.
if (xxx == TRUE)
{
}
xxx 값이 0도 아니고 1도 아닌 값(하지만 참인)을 가진 경우에는 골탕을 먹게 되기 때문이다.

오늘 stackoverflow를 구경하다가 재밌는 사실 하나를 알게되었다.
많은 사람들이 나만큼이나 위 두가지 스타일을 싫어한다는 것이다.
어떤 코딩 스타일이 가장 거지같다고 생각하나요?

내가 위에서 말한 2가지 스타일이 1등과 3등을 차지 했다니 아마 저런 스타일을 사용하는 사람들은 잘 믿기지 않을 것이다.
재밌는 답변과 댓글들이 많으니 관심있는 사람들은 위 포스트를 한번 읽어보기 바란다.
나는 아래 댓글이 가장 재밌고 인상적이었다.
Damn. We say "if it's raining, open your umbrella" and NEVER "if it's true that it's raining, take your umbrella"... Testing explicitely against boolean is as verbose and as un-natural as the second example
저작자 표시 비영리 동일 조건 변경 허락
신고
  1. Favicon of http://eslife.tistory.com BlogIcon esstory at 2011.10.29 14:55 신고 [edit/del]

    상수를 앞에 쓰는 건 이제 손에 익어서 항상 지키게 되는데 ㅎㅎ
    컴파일러가 좋으니 이제 이런 학습들도 구닥다리가 되는거네요 ㅎㅎ

    Reply
    • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2011.11.02 09:58 신고 [edit/del]

      네, 책에서 (또는 다른 사람이) 말하는 내용을 그대로 믿지말고 한번 잘 생각해보고 걸러서 받아들이는 자세가 중요하다고 여기어집니다.

  2. Favicon of http://blog.spowner.com BlogIcon spowner at 2011.12.01 11:00 신고 [edit/del]

    안녕하세요.
    저같은 경우도 0 == xxx 싫어합니다. 사람이 사람보기 편하게 코딩해야지 이건 뭥미.. 텍스트에디터로 코딩하는것도 아니고.. 상수도 마찬가지.
    하지만 저는 명시적으로 true/false를 적어주는것을 선호합니다. 다양한 언어들을 접하고 사용하다보니 명시적으로 적지 않으면 제가 눈에 확 안들어오더라고요

    Reply
  3. subong at 2012.01.31 12:29 신고 [edit/del]

    if문의 경우 true를 쓰지 않는 부분에 대해선 공감합니다만
    false의 경우엔 !를 사용하는경우 상황에 따라 눈에 잘 안들와
    잘못 읽는 경우도 생기는 갓 같아 false인 경우에는 명시적으로 쓰고있네요.
    if (!variable)
    =>
    if (variable == false)

    Reply
    • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2012.01.31 19:06 신고 [edit/del]

      if (variable == false)는 전혀 문제가 없고 보기에도 좋은 코드입니다.
      if (!variable) 도 역시 보기에 좋습니다.

      이런 경우에 저는 최대한 다른 사람들이 많이 사용하는 스타일을 사용하려고 합니다. 이렇게 하면 많은 경우에 유리합니다. (특히 스타일을 가지고 누군가 따질 때. C/C++하는 사람들이 흔하게 맞게 되는 일이죠)
      C/C++ 세계에서는 if (boolean_variable == false)보다는 if (!boolean_variable) 이라고 생각이 되어요.

  4. gcd at 2012.02.22 06:47 신고 [edit/del]

    안녕하세요. 혹시 스캇형이 EC++11을 내놓지 않았을까, 하는 정보를 찾아 헤매다 들렀습니다.
    처음(?) 들렀다 생각했는데 변수 자리에 놓는다는 typedef 관한 글을 봤던 기억이 나네요.

    어쨌든, 말씀하신 스타일이 저와 매우 비슷해서 그냥 지나갈 수가 없겠더군요 ^^;
    은근한(?) 스페이스의 매력이 있는 것 같습니다. (웹쪽에서는 사이즈적인 손해가 좀 있지만 크게 신경 쓸 것도 아니고...)

    0 == foo는 좋다길래(?) 따라해보려 했지만 몸이 거부했기에 결국 포기하고 말았었네요.
    (마침 최근 댓글에 조엘에 관한 것이 있어서 떠오르는데, 그 사람도 '정말 효과가 있든 없든' 그런 방어적 프로그래밍 습관을 가진건 좋은 징조라고... 면접하는 법이었나... 거기에서 그랬던 것 같네요.)

    저는 bar == true는 보고 있으면 피부에 뭔가 기어가는 기분이 드는군요. (return 타입 bool일 때 int를 바로 넘기면 경고 뜨는 걸 보는 기분으로요...)
    하여간 if ( a && b == true ) 같은 상황이 되어버리면 연산자 우선순위까지 괜히 헷갈려서 좋지 않은 것 같습니다.

    가독성 면에서는 if (! boo) 하고 ! 다음에 공백을 하나 주는 것도 괜찮을 것 같네요.
    여기에 목숨 걸면 #define if_not(x) if (!(x)) 해놓고 쓰는 것도 나쁘지 않을지도..(후자는 농담입니다 ㅠㅠ)

    Reply
    • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2012.02.22 10:16 신고 [edit/del]

      예, 조엘이 면접하는 법에서 그런 말을 했었죠.
      1. 상수를 좌측에 쓰면 좋은 징조이다
      2. C++에서는 소멸자를 항상 가상 소멸자로 선언해야한다.

      저는 조엘 온 소프트웨어를 아주 재밌게 읽었고 거의 모든 내용에 동의하는데 딱 저 2가지에 대해서만은 반대입니다^^

submit
Writing Solid Code - 10점
Steve Maguire 지음, 나윤석 외 옮김/높이깊이

몇 일전 deview 2011 행사 중 한 세션에서 재미있는 이야기를 들었다.
 NHN 김정민 이사의 세션이었는데, 이런 말을 했다.
애플, 마이크로소프트, HP 같은 회사에서 15년 동안 일했던 (지금은 NHN에서 일하고 있는) 송창현 이사가 예전에 우리회사에 면접을 보러 왔을 때 잘하는 게 뭐냐고 물어봤더니,
"저는 meticulous code reader입니다. 남의 코드를 아주 꼼꼼하게 읽어줄 수 있습니다."
대부분의 경력을 많이 가진 사람들은, 저는 유닉스를 10년을 넘게 다뤄서 커널 구석 구석까지 깊게 알고 있습니다. 오라클 전문가입니다 라고 말하지 저런 식으로 말하지는 않는데, 김정민 이사는 그게 상당히 인상적이고 멋있어 보였다고 한다.

나 또한 그 말이 멋있어 보인다는데에 완전히 동의한다.
저는 자바스크립트만큼은 누구보다 잘할 자신이 있습니다, 라는 말(또는 뻥)보다 훨씬 멋지지 않은가?

직장 생활을 하다보면 Meticulous code reader가 거의 없다는 것을 쉽게 알게 된다. - 나는 이전에 다니던 직장에서 여태껏 그런 사람을 딱 1명 만나봤다.
여러분이 후임이 있다고 치자. 어떤 기능을 구현해달라고 일을 주고 후임이 나중에 다 만들었습니다 했을 때, 또는 만들고 있는 도중에, 코드를 한줄 한줄 다 꼼꼼하게 읽어주고 피드백 해준 적이 있다면, 당신은 좋은 Meticulous code reader가 될 수 있는 가능성이 있다. 거의 대부분의 사람들은 그렇게 하지 않는다.

갑자기 이런 이야기를 하는 이유는, 최근에 Writing Solid Code라는 책을 읽으면서 이 책의 저자인 Steve Maguire가 그런 Meticulous code reader 라는 생각이 들었기 때문이다.
이런 사람들은 회사에 꼭 필요하다. 마이크로소프트가 10년 넘게 황제의 자리를 차지할 수 있었던 이유는 이런 사람들이 많이 있었기 때문일 것이다.

이 책에서는 정교하고 튼튼한 프로그램을 짜기 위한 많은 기술들을 배울 수 있으며, 또한 프로그래머가 프로그램을 만든다는 것 대해서 가져야할 바람직한 자세를 배울 수 있다.
매 챕터가 끝날 때에는 '생각할 점'이 나오는데, 여기에도 좋은 내용들이 참 많다. 부록에 답까지 있으니 모두 꼼꼼하게 읽어보도록 하자.
인터넷 어딘가에서 번역이 최악이라는 평가를 본 것 같은데, 이 책의 번역은 정말 잘 되었다고 생각한다. 부분 부분 약간 어색한 단어 선정이 보였던 것 같긴 하지만, 나는 왜 최악의 번역이라고 하는건지 이해할 수가 없다.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
얼마전에 안랩이 판교에 사옥을 짓고 입주를 했는데, 이번 11월 9일 18시 30분에 오픈하우스 행사를 한다고 한다. 외부인들을 초청해서 사옥을 소개시켜주는 자리인데, 초대권을 받으려면 블로그나 트위터에 소개를 해야한다고 해서 나도 한번 이렇게 신청을 해본다.

내가 생각하는 안철수연구소의 이미지는 커널 레벨 드라이버를 만드는 아저씨들이 가득하고, 사무실에서 홀애비 냄새도 날 것 같은 여의도의 조그만 회사였는데, 이번에 새로 지은 사옥을 보고서 돈을 많이 썼구나하고 깜짝 놀랐다.
IT 회사들도 이렇게 신경써가며 예쁘게 건물을 꾸미는 추세를 몹시 환영한다. 좋은 사옥을 가진 IT 회사들이 훨씬 많아졌으면 좋겠다.



안랩의 직원은 700명 정도로 알고 있는데, 건물은 1000명도 훨씬 넘게 들어갈 수 있을 것으로 보인다.
안철수연구소에서 일해보고 싶었던 사람들에게는 지금이 기회라는 뜻이기도 하다.


사진을 보다보니 안랩 사옥 중에서 부러운 것 중 하나가 있었는데 바로 운동 시설이다.
휘트니스 클럽은 네이버의 그린팩토리에도 없는 공간인데, 참 과감하게 결정했다는 생각이 든다.
그런데 사람들이 이 넓은 공간을 얼마나 덜 이용하게 될지 또한 몹시 궁금하다. 나중에 꼭 한번 물어봐야겠다.
뭐 비효율적으로 운영된다 할지라도 직원들의 건강을 염려해서 이런 공간을 마련해준 회사가 참 보기 좋긴하다.

아래 안랩 기업 블로그에 가보면 더 많은 사진들을 구경할 수 있다.

저작자 표시 비영리 동일 조건 변경 허락
신고

'에세이' 카테고리의 다른 글

Write in C  (0) 2012.04.23
Devon 2011, 왜 김택진이 욕을 먹어야 하는가  (2) 2011.11.28
안철수연구소 오픈 하우스 이벤트  (0) 2011.10.22
플라워 바이 겐조  (0) 2011.07.12
클라우드가 더 안전하다  (8) 2011.06.13
조그만 술집, 여행  (4) 2011.04.24

submit

출처 : http://www.kubuntu.org/feature-tour


GNOME3에 너무 많은 기대를 해서 그런가. 이번 우분투 11.10은 많이 기대가 되서 알파3 부터 받아서 사용하고 있었는데, 기대가 큰 만큼 실망도 컸다.
문득 KDE는 얼마나 좋아졌나 싶어서 쿠분투를 설치해서 한달여 동안 사용해왔는데, UI 콘트롤들도 다 하나같이 고급스럽고 부드럽게 동작하는게 아주 만족스럽다. 예전에 2008년도 쯤 쿠분투를 설치해봤었을 때 그 조잡함에 충격 받았던 기억이 남아있었기 때문에 사실 좀 놀랐다. 아마 KDE4로 올라오면서 많이 좋아진 것 같다.
한달 동안 많이 익숙해 졌겠다, 정식 버전도 나왔겠다. 이번 주말에는 새로 이미지를 받아서 kubuntu로 데스크탑을 싹 정리했다. 아, 참 깔끔하고 좋다.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
아이디어맨 Idea man - 10점
폴 앨런 지음, 안진환 옮김/자음과모음(이룸)
언젠가 폴 앨런이라는 남자를 이 글에서 처음 알게 되었다. 마이크로소프트의 공동 창업자였고, 돈이 워낙 많아서 좋아하는 NBA 팀을 사버리고, 좋아하는 극장이 망한다고 하자 그것도 사버리고 -_-; 언제든지 전화만 하면 달려오는 밴드 멤버들이 있고 세계에서 가장 비싼 요트를 가진 남자.

충분히 흥미가 갈만한 사람이긴 하지만, 미안하게도 나는 빌 게이츠에 대해서 더 관심이 있었다.
이 책에서 왠지 빌 게이츠의 이야기가 잔뜩 나올 것 같아서 읽어봤는데 예상이 딱 적중했다. 빌 게이츠의 성격이라던지 프로그래밍 실력이라던지 내가 평소에 궁금해 했던 내용들이 매우 많이, 그것도 적나라하게 쓰여있어서 정말 재밌게 읽었다. 그동안 읽었던 다른 책들에서는 찾아볼 수 없는 내용들이 많았다. 초창기 마이크로소프트의 분위기와 모습들도 너무 재밌게 그리고 부러워하면서 읽었다.

찰스 시모니나 개리 킬달 같은 전설적인 프로그래머들도 조연으로 나오고 Mark Zbikowski(윈도 PE파일의 설계자이며 PE 맨 앞의 헤더에 MZ라고 자기 이름을 쑤셔넣은 걸로 유명한) 같은 위대한 해커는 빌 게이츠 앞에서 벌벌 떠는 '일개' 프로그래머로 출연한다.

미래를 만든 Geeks이라는 책을 쓴 애플에서는 꽤 유명했던 앤디 허츠펠드가 스티브잡스에게 개갈굼을 당하는 장면도 인상적이었다. 어느날 맥을 자랑하고 싶어서 빌 게이츠와 폴 앨런을 초대해서 맥을 보여주려고 하는데, 부팅이 안되자 굴욕감에 데모를 시연하던 앤디 허츠펠드에게 손님들을 앞에 두고 잡스가 쌍욕을 퍼붓는 내용이 있는데, 빌 게이츠와 스티브 잡스를 보면서 CEO가 싸가지가 없다고 적어도 회사가 망하는 건 아니구나 하는 것은 확실히 알게되었다.

책의 2/3 부터는 마이크로소프트에서의 내용이 끝나고 스포츠 팀을 만들고 음악을 하는 내용이 나온다. NBA에서는 클라이드 드렉슬러가 주연으로 출연하고 마이클 조던이 잠깐 나오는데 거기까진 재밌다. NBA 이후의 내용부터는 관심이 없어서 책을 덮었다.

마이크로소프트와 빌 게이츠를 좋아하는 사람들은(요즘엔 별로 없는 것 같지만) 꼭 한 번 읽어보기 바란다. 너무 재밌는 책이다.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit