안녕하세요, 개발자 윤진입니다.


코더로서 개발을 막 시작하고 얼마 후-

코딩컨벤션으로 개발자들끼리 핏대를 세워가며 언성을 높이는 것을 목격하였습니다.

당시에는 '간단한 함수의 경우 헤더에 함수를 정의해도 되는가'라는 주제로 피튀기게 양 진영이 거세게 싸웠는데요,

이후에 파일명, 함수명, 변수명의 이른바 '온갖 것에 대한 작명'에 대한 혈투가 개전되어, 모두가 가열차게 답메일을 보내 메일함이 폭발한 적이 있습니다.

그리고, 프로그래밍에서는 '작명'이 가장 어렵다는 결론을 내리며 훈훈하게 마무리되었죠.

'작명'이 가장 어렵다는 결론은 아직까지 유효합니다. :)

함수나 변수의 역할을 그 이름만으로 정확하게 파악할 수 있게 만드는 것은 프로그래밍의 영역이라기 보다는 예술의 영역에 가깝습니다.

그리고 이 영역에서 프로그래머의 센스와 자질이 드러나죠.


사실, 코딩컨벤션은 코드의 성능이나 안정성과는 거리가 멀지만,

코드독해에 직접적인 영향을 주는 요소입니다.

눈에 익숙하게 들어오는 코딩컨벤션이 아무래도 빨리 읽히는 법이죠.

그렇기 때문에 개발자들이 그렇게나 코딩컨벤션에 열을 올립니다.

코드는 짜고 난 뒤에도 수많은 개발자들에게 되풀이되며 읽히기 때문에, 개발자들의 원활한 정신상태를 위해 코딩컨벤션을 제대로 지켜줘야합니다.

개인적으로 일관성없는 코딩컨벤션으로 점철된 코드를 보면, 두통이 생기며 고치고 싶다는 욕망이 생깁니다.


C언어로 개발을 할 때는 기본적으로 linux_kernel_coding_style을 따랐습니다.

리눅스 스타일 문서에서는 작명에 대한 기준도 볼 수 있습니다.


4. 이름짓기 


C 언어는 간소한(Spartan) 언어이므로, 이름짓기 규칙도 이를 따라야 한다. Modula-2 나 파스칼 프로그래머와는 달리, C 프로그래머들은 ThisVariableIsATemporaryCounter 와 같은 귀여운(?) 이름을 사용하지 않는다. C 프로그래머들은 "tmp" 와 같이, 쓰기 쉽고 이해하기도 그리 어렵지 않은 이름의 변수를 사용할 것이다.

하지만, (대소문자를 섞어쓰는 것은 보기 안좋지만) 전역 변수에 대해서는 반드시 충분한 설명이 될 만한 이름을 붙여야 한다. 전역 함수의 이름을 "foo" 라고 짓는 것은 범죄 행위(shooting offense) 이다 (FIXME!)

전역 변수는 (정말로 필요한 경우에만 사용하자) 충분한 설명이 될 만한 이름을 가져야 하며, 이는 전역 함수에 대해서도 마찬가지이다. 만약 활동 중인 사용자의 수를 세는 함수를 작성했다면 이 함수의 이름은 "count_active_users()" 혹은 이와 비슷한 형태가 될 것이며, "cntusr()" 과 같은 형태가 되어서는 안 된다.

함수의 이름에 타입을 포함시키는 방식 ("헝가리안 표기법"이라고 한다) 은 멍청한 짓이다. 컴파일러는 타입을 알고 체크할 수 있으며, 이러한 표기법은 단지 프로그래머를 혼동스럽게 할 뿐이다. MicroSoft 에서 버그가 많은 프로그램들을 만들어 내는 것을 보면 당연하다.

지역 변수는 짧게 핵심만을 나타내는 이름을 사용한다. 만약 어떤 임의의 정수 루프 카운터가 필요하다면 그 이름은 "i" 가 될 것이다. 이를 "loop_counter" 라고 표기하는 것은 오해를 살 만한 여지가 없는 경우에는 생산적이지 않다. 마찬가지로, "tmp" 일시적인 값을 가지는 어떤 타입의 변수에도 사용될 수 있다.

혹시 여러분이 지역 변수 이름이 많아져 뒤섞이지 않을까 걱정하고 있다면, 여러분은 함수-성장-호르몬-불균형 증후군이라는 다른 문제를 가지고 있는 것이다. 6장 (함수) 부분을 보기 바란다.



C언어를 사용할때 대문자는 #define문 정도에서만 사용하였습니다.

온갖 이름은 소문자와 '_'(언더스코어)의 조합만으로 아름답게 명명되었죠.

함수나 변수도 그 적용범위에 따라 제각각의 작명법이 있었지만 모두 소문자와 '_'만으로도 충분했습니다.


그렇지만, C#의 세계에서는 C언어의 linux_kernel_coding_style은 '읽기 쉽지 않은' 코딩 컨벤션의 부류에 들어가더군요.

그 동안 줄곧 언더스코어의 세계에서 행복하게 살았는데,

C#의 세계에서는 (상대적으로 그리고 개인적으로) 읽기 번거로웠던 camelCase와 PascalCase의 세계에서 살아나가야 합니다.

이 세계에는 '_'는 죄악과 마찬가지입니다.


Capitalization Rules for Identifiers

To differentiate words in an identifier, capitalize the first letter of each word in the identifier. Do not use underscores to differentiate words, or for that matter, anywhere in identifiers. There are two appropriate ways to capitalize identifiers, depending on the use of the identifier:

  • PascalCasing

  • camelCasing


Microsoft의 코딩컨벤션 문서에서는 camelCase와 PascalCase를 읽기 쉽다고 콕 찝어 표현합니다.

Microsoft의 입장과 같은 맥락에서,

1) '_'로 단어간 구분한 문장과,

2) 대문자로 구분한 문장을 두고,

어느 쪽이 빨리 읽히는지 실험한 자료도 읽은 기억이 납니다.

그 때는 대문자로 구분한 문장이 더 빨리 읽혔기에 자바에서 camelCase를 선택했다고 주장하는 글을 읽은 기억이 있습니다.


하지만, 비교적 최근인 '10년에 Eye tracking으로 독해속도와 오타교정속도을 조사한 논문[각주:1]이 나옵니다.

이 논문은 과거에 읽었던 내용과는 상반되는 결론을 보여주는데요.

독해속도에서 with_underscore 표기법이 withoutUnderscore 표기법보다 무려 20% 정도나 빠르다고 합니다.

오타교정속도도 독해속도가 빠른 with_underscore 방식이 더 빨랐습니다.

Microsoft가 어떤 기준으로 camelCase나 PascalCase가 더 읽기 쉬운 코딩컨벤션으로 선택했는지 모르겠지만,

분명, 치밀하게 고민하고 결정했다고 생각합니다.


어느 코딩컨벤션이 더 좋든, 기본적으로 코딩컨벤션은 기존 코드에서 사용한 코딩컨벤션을 따라주는게 맞습니다.

만약 기존 코딩컨벤션이 정 맘에 안들면, 

해당 커미터들과 치열하게 싸워 결론을 내린 후,

코드 전체에 동일한 코딩컨벤션을 유지시켜면 됩니다.

실제로 이런 번거로운 과정을 거쳐, 자동화툴로 코딩컨벤션을 바꿔서 diff가 수만줄 남긴 기억이 있습니다.


어쨌든, C#의 세계에 발을 담그는 지금부터,

camelCase와 PascalCase에 적응하고자 합니다.

머리가 굳었으니 그만큼 시간이 더 걸리겠네요.


그럼 좋은 하루 보내세요.



  1. Bonita Sharif and Jonathan I. Maletic, "An Eye Tracking Study on camelCase and under_score Identifier Styles", 2010, Kent State University [본문으로]
  1. 2017.02.13 13:31

    비밀댓글입니다

    • 안녕하세요, 양인황님. :)
      지적하신게 맞습니다. 이제 타이젠도 객체지향으로 나아가고 있어요. 현재는 홈피 등지에서 알 수 있듯 아직은 개발중인지라 정확히 어느 시점에 오픈이 될지는 모릅니다. 우선은 Xamarin 코드부터 보시는게 도움이 될 겁니다. ;)


안녕하세요, 타이젠 개발자 윤진입니다.


2015년 마지막 날을 맞이하여,

<아프니까 개발자다> 블로그 총결산을 진행하고자 합니다.

제 블로그를 찾아주시는 극소수의 개발자분들조차 총결산 따위에 관심없으시겠지만,

블로거로서 지난 한해를 돌아보고,

더 나은 내일을 구상하기 위해 2015년을 돌아보고자 합니다.


<아프니까 개발자다> 블로그 정보를 훑어보겠습니다.

그 동안 총 159개의 글을 썼습니다.

대부분의 글은 외부에 발행한 공개글이고,

열개 남짓한 글은 차후에 게시하기 위해 가다듬고 있는 중입니다.

댓글은 글마다 평균 0.6개 정도가 달리고 있습니다.

타이젠에 대해 전문적인 내용을 다룬 포스팅에는 댓글이 거의 없네요.

문의가 없다는 것은 그만큼 완벽하게 포스팅을 하고 있는 것이겠죠...?


마지막에 블로그 개설일이 뚜렷하게 찍혀있습니다.

2015년 3월 1일!

그렇습니다. 올해 3월 1일 삼일절에 블로그를 개설하였습니다.

일부러 삼일절을 되새기기 위해 굳이 그날 개설했습니다.

(농담 아닙니다. 히히;)




제 블로그는 주로 구글링으로 접근해서 들어오는 분이 많습니다.

불과 두어달 전까지만 해도 네이버를 통해서 들어오는 분들이 많았는데요,

어느 순간 구글이 치고 올라오기 시작하더니 압도적으로 수치가 올라가고 있습니다.

1위는 구글, 2~5위는 네이버, 6위는 다음입니다.


10위에 티스토리가 있네요.

아마 포스팅을 할때마다 티스토리 주제별 스토리에 게재가 되는데요,

그 때 타고 오는 분들이 있겠지요.


11위에는 카카오톡입니다.

카톡으로 제 블로그를 검색해서 오시는 분들도 있군요.

아직 1위인 구글의 1/100에 불과하지만 차츰 점유율을 높이길 기대해봅니다.


13위, 구글 재팬으로 들어오는 분도 있고,

14위, 구글 인도도 제법 있네요.

16위에는 구글 캐나다가 보이고,

20위에는 구글 호주도 있습니다.

영어공부를 열심히 해서 포스팅을 영어로도 해야하지 않나 고민하게 만드네요.


매달 방문한 사람수를 보며 어떤 글이 관심을 받았는지 정리해보고,

올 한해의 방문트랜드를 엿보고 내년을 예상해보겠습니다.



사실 개설한 첫달 3월은 하루 방문자 수가 극히 미미하였습니다.

3월 1일부터 31일까지 하루 평균 2명 정도가 다녀갔네요.

겨우 한 명이 방문한 14, 15, 16, 23일은 아마 제가 방문한게 아닌가 싶네요.

게다가 3, 12, 13, 18, 19, 20, 22, 24, 25, 26, 27일은 방문자가 없습니다.

블로거가 방문하지 않는 블로그!

대단합니다;


29일에 방문자가 폭증(?)한 것은 코딩컨벤션을 다룬 세번째 글때문입니다.

[Coding convention] 코딩의 기본, 시대의 흐름으로 살펴본 헝가리안 표기법

사실 첫달에 하루 방문자수가 두자리수가 되리라고 생각하지 않았는데요,

아직도 세상은 코딩컨벤션으로 다투는 개발자로 가득차 있어서,

제 블로그 기준으로 '많은' 개발자가 다녀간 것으로 보입니다;




4월은 매우 고무적인 달입니다.

하루 평균 방문자수가 무려 3명이 넘는 기염을 토하였습니다.

그 덕에 방문자 수가 한 명도 없는 날은 12일(일) 하루뿐입니다.

원래 전통적으로 토/일은 제 블로그가 굉장히 한산하죠...


이 달에 가장 인기있던 포스팅은,

오픈소스 타이젠에서 소스 형상관리를 위해 사용하는 'git'과 관련된 내용이었습니다.

[git] 깃의 속사정, 4대 원소를 파헤치기

많은 개발자들에게 필수툴로 자리잡은 git의 위력을 실감할 수 있습니다.

위의 포스팅 이후에도 git에 대해서는 다양한 이야기를 나누고 싶었지만,

최근에 git과 관련된 정보가 인터넷에 넘쳐나고 있어서 자제하고 있습니다.




5월은 거의 매일 두자리 수의 방문객을 유치한 혁신의 달이었습니다.

4월달의 평균 3명 방문했던 블로그가 평균 34명 방문하는 블로그가 됩니다.

무려 10배가 늘어났네요.

이 달의 격한 감동은 아직도 마음 깊숙한 곳에 자리잡고 있습니다.

하루 3명오던 블로그에 30명이라니!

게다가 5월 21일에는 무려 187명이 방문합니다.

세자리수를 처음으로 찍었습니다.


[Tizen] 타이젠 최초의 모바일 기기, "Z1"의 늦은 개봉기

5월 21일 포스팅은 타이젠 상품과 관련된 내용이었습니다.

타이젠을 다루는 블로그에 타이젠 상품과 관련된 포스팅이 관심받지 못하면 문제가 있는거겠죠;

서남아 시장에만 출시한 Z1의 개봉기를 간단하게 다루었었는데요,

개발자의 손에 하드웨어를 쥐어주면 참 많은 걸 할 수 있겠구나 생각이 들었습니다.



6월에는 하루평균 백여명이 방문하게 됩니다.

5월에 비해 3배 이상의 성장율을 달성하게 됩니다.

5월에는 31일 중 고작 이틀동안만 백여명 이상의 방문자를 유치했었는데요,

6월에는 거의 절반에 가까운 14일동안 백여명 이상의 방문자를 유치하였습니다.


그 중 가장 많은 사람이 찾아주었던 6월 13일에는 타이젠 보안의 핵심,

스맥을 다룬 포스팅이었습니다.

[SMACK] 스맥 레이블을 긋기 위한 manifest의 모든 것 - 파일편

대규모 플랫폼 중에서 타이젠이 가장 적극적으로 스맥을 사용하고 있습니다.

스맥을 알고 싶다면 타이젠 플랫폼을 분석하는 것도 의미가 있을 겁니다. 




7월에는 하루 평균 122명의 방문객이 다녀갑니다.

6월의 100명에 비해 22명이 더 늘어났습니다.

평일에는 거의 어김없이 세자리수를 유치하였고,

주말에는 역시 어김없이 두자리수에 머물고 있습니다.

제 블로그가 평일용으로 확정된 것이 7월달부터가 아닌가 싶습니다.

다들 업무시간에만 제 블로그를 찾는 것일까요?

그래서 업무 외의 시간에도 방문자를 유치할 수 있도록-

여러가지 다양한 내용을 다뤄야되겠단 생각을 했습니다.


7월에 가장 인기가 많았던 포스팅은,

[Tizen] 타이젠 스토어 182개국 오픈 중 4개국 유료판매가능

타이젠 앱스토어의 유료판매 정책에 대한 내용입니다.

182개국 중 4개국(인도, 방글라데시, 스리랑카, 네팔)에서 유료판매가 가능하게 되었죠.



8월에는 7월과 거의 유사한 수의 방문객이 다녀갔습니다.

7월에 122명이 다녀갔다면 8월에는 평균 123명이 다녀갔습니다.

하루 평균 2명 방문했던 블로그에 123명이 방문한다면 그야말로 대사건이긴 하지만,

100여명에서 정체된다면 아무래도 한계점에 다다른 것일 수도 있겠네요.


사실 8월에는 포스팅을 거의 하지 못한 기억이 납니다.

8월 29일에 서울 서초에서 타이젠 행사에서 세션발표를 맡게되어,

여러가지 준비를 하느라 정신없었죠.

[Tizen] 타이젠 DEVLAB @SEOUL 후기

위의 글이 가장 많은 방문자가 다녀간 날에 포스팅한 글입니다.

서울에서 열린 첫 타이젠 데브랩이니만큼 여러가지 많은 것을 느낄 수 있었습니다.




9월에는 하루 평균 120여명에 멈춰있었던 방문자수가 조금 증가하게 됩니다.

평균 145명으로 약 20여명의 방문자가 더 늘어났습니다.

타이젠에 관심을 가지고 있는 사람이 늘어났다기보다는,

일반적인 개발방법에 대해 다룬 글을 몇 개 올려서 외부 소프트웨어 개발자가 유입된 것으로 보입니다.


그 중 가장 많은 방문자를 유입한 날에 작성한 글은,

[소프트웨어 개발] Man-Month 허상과 히어로 개발자입니다.

위의 글은 타이젠 플랫폼을 만들고 계신 분들 중에 없어서는 안될 개발자분들을 떠올리며 작성했죠.

지금은 좀 더 늘어나긴 했지만,

저 글을 썼었던 당시에는 5명의 히어로 개발자 분들을 염두했죠.

물론 그 다섯 분들은 자신이 히어로 개발자들인 것을 인지하지 못하실 수도 있겠네요. :)

지극히 개인적인 생각입니다만,

저런 훌륭한 개발자들이 타이젠 플랫폼에 남아있는한,

타이젠은 점점 흥미로운 플랫폼으로 변모해나갈 것임을 확신할 수 있습니다.




시월에는 평균 145명 방문자가 192명으로 늘어납니다.

어느새 평균 200여명의 문턱에 다다르게 되었습니다.

이런 날이 이렇게 빨리 오게 될 줄은 상상하지 못했죠.


사실 시월에는 타이젠 외에 다양한 주제를 다루었습니다.

우선 삼성 오픈소스 컨퍼런스를 주제로 몇 건 포스팅하였죠.

삼성 대학생 프로그래밍 경진대회가 열린 달이기도 하고요.

코리아 리눅스 포럼에 대해서도 살짝 포스팅을 했습니다.

그래도 가장 많은 사람이 방문한 글은 SCSA에 대한 글이었습니다.

[SCSA] Samsung Convergence Software Academy를 말하다

삼성에서 만든 굉장히 독특한 제도이니 만큼,

외부의 관심도 많았습니다.

더불어 개인적으로도 아주 관심이 많습니다.

앞으로도 SCSA 전반을 계속 주시하며 정보를 '적극적으로' 갱신할 생각입니다.




11월은 앞으로 돌아오지 않을 호시절과 같은 달이었습니다.

이전달의 평균 192명 방문자는 이제 평균 378명으로 거의 두 배 가까이 늘어납니다.

방문자수가 폭발적으로 늘어나게된 이유는 기어S2가 출시되면서 타이젠에 관심이 많아진 것이겠지요.


가장 방문자가 많았던 글은,

[Tizen] 타이젠 세번째 웨어러블 기기, "Gear S2" 리뷰

위의 글이었습니다.

개발자들의 관심을 받게된 만큼,

타이젠은 생태계 구축에 더욱 힘을 쏟아야할 때입니다.



이 글을 쓰고 있는 12월 25일 기준으로,

하루 평균 218명의 방문자가 블로그를 찾고 있습니다.

기어 S2가 출시된 후 시간이 많이 흘렀기에 기어S2로 검색하여 들어오는 사람은 많이 줄었습니다.

그 대신 타이젠을 키워드로 들어오는 사람들이 200명이 넘습니다.


물론 이미 널리 알려진 여러 플랫폼들을 주제로 다룬 블로그는,

<아프니까 개발자다> 보다 10배 혹은 100배 많은 방문객을 유치하고 있겠죠?

내년에는 타이젠이 더 많은 사람들에게 사랑 받아서 덩달아 제 블로그에도 다시 호시절이 오면 좋겠습니다. :)

역시 타이젠 관련 블로그는 타이젠이 흥해야 같이 살아난다는 만고의 진리를 다시 한 번 확인하게 됩니다.


마지막으로 재미삼아서,

최근에 분석하기 시작한 구글 애널리틱스 분석자료를 보겠습니다.



제 블로그에 재방문자가 40%나 됩니다.

재방문자가 있다는 것은 뭔가 쓸만한 글이 있다는 반증이겠지요?

재방문자들을 실망시키지 않도록 2016년에는 흥미로운 주제를 더 많이 찾아내겠습니다.

"단골이여, 영원하라."



방문객은 평균 2~3분 정도 블로그에서 글을 읽었습니다.

2~3분이 결코 긴 시간은 아닌 만큼,

좀 더 퀄리티가 높은 글을 공유해야겠다는 생각이 듭니다. 



방문객은 1.5개 정도의 글을 읽고 돌아갔네요.

검색한 하나의 글만 보고 가는 분들도 있겠지만,

두개 이상을 보고 가는 분도 있네요.

흥미롭군요.



위의 그래프는 매일매일 시간에 따라 방문자를 나타낸 겁니다.

예외없이 평일 오후 3시에 그래프가 정점을 찍습니다.

제 블로그는 오후 3시에 들어오기 좋은 블로그인가 봅니다.

도대체 그 시간에 무슨 일이 벌어지고 있는 건가요?


이상으로 어쩌면 제게만 유의미할 지 모르는 2015 총결산을 마치겠습니다.

2016년 새해 복 많이 받으세요.

2016년 총결산때 다시 찾아뵙겠습니다.


감사합니다.

끝_




  1. 시스템가이 2015.12.31 23:44

    타이젠에 대해 이렇게 멋진 블로그를 운영하시는 분이 또한분 계시다니 감동이에요 ^^ 총 결산 글을 보니 다른 글들도 보게 되네요 잘 읽고 갑니다 ^^

    • 안녕하세요, 시스템가이님.
      새해 복 많이 받으세요~!
      시스템 가이님의 댓글을 보니 더 흥미로운 글을 많이 써야되겠다는 생각이 듭니다. 아직은 많이 부족하니 올 한해 바짝 허리띠를 졸라매야겠네요 :) 좋은 말씀 감사해요!

  2. 코코콩 2016.01.05 18:12 신고

    오후 3시는 점심먹고 업무에 몰두하다가 안풀려서 쉬는타임이죠 ㅋㅋㅋ

    • 제 블로그를 보면서 쉬는 분이 계실 수도 있겠군요.
      3시 고객을 위해 좀 더 재미나게 읽을거리를 준비해야겠네요. :)

+ Recent posts