저는 개인적으로 앙드레 미쉘의 코드를 본 이후로

네이밍과 코드 스타일이 많이 바뀌었습니다.

바뀐 부분은 크게 두가지입니다.

말 그대로 Naming, 함수나 변수명을 짓는 네이밍이 많이 바뀌었습니다.

그 다음이 바로 코딩 스타일입니다. 

두 가지입니다.


1. 타입 선언은 콜론 ":" 뒤에 한 칸 띄어쓴다.

public function getType(): String
{
     var type: String = "customType";
    
     return type;
}


2. 파라미터는 () 안에서 앞 뒤로 한 칸씩 띄어쓴다.

public function parseData( xml: XML, parseType: ParseType ): void
{
     if( parseType == ParseType.BIG_ENDIAN )
          checkHeader( xml );
}

중요한 정보인 타입과 파라미터를 한 칸 띄움으로써 눈에 잘 들어오게 합니다.

우리는 보통 코드를 볼 때 그 안의 내용보다는 함수명이나 파라미터 명, 타입등을 먼저 보고

그 파악이 끝난후에 집중해서 내용을 보기 때문에

파라미터와 타입에 중요도를 주는 것은 매우 효율적이라고 봅니다.


3. 코드의 끝부분에 필요없는 공백은 남기지 않는다.

요고 중요합니다.

에피그램의 현우도 강조하는 부분인데

다른 사람의 소스에서 메소드의 리턴 타입을 고치려고

"맨 끝이겠거니..."하고 무심코 커서를 대충 딱 찍었는데

허공에 떠있는 입력 커서를 볼 때면

코딩의 맥이 끊기기도 하거니와 

도대체 저 횡 스크롤은 뭥미 ㅇ_ㅇ???


이처럼 쌩뚱맞은 스크롤바는 불편하기 이를데 없죠...

(남의 코드에서 빈 칸만 지우고 커밋하려다가 SVN 뻑날때의 그 허무함이란...)



그리고 제가 항상 머릿속에 넣어두고 네이밍을 하는 몇가지 규칙이 있습니다.



1. 콩글리쉬 절대 No.

함수명은 동작을 하는 역할이기 때문에

함수명은 "동사"형태거나 "동사 + 목적어"로 끝나야 알아보기 쉽다고 생각합니다.

몇 가지 예를 들어보자면

 - xmlParse : xml(주어) + parse(동사) 

즉, 해석해보면 xml이 무언가를 분석한다는 이야기입니다.

아마 xml을 분석한다는 뜻일텐데 국어식 어순때문에 영어로는 해석이 되지 않습니다.

parseXML이 더 적당할 것입니다.

 - arcDraw() : arc(주어) + draw(동사)

위와 같은 예제인데 아마 가장 흔한 네이밍 실수가 아닐까 합니다.

호를 그리기 위한 메소드라면 drawArc() 더 올바른 표현이 아닐까 합니다.



2. 가능한한 함수명이나, 변수명은 풀어쓴다.

strTitle, nIndex, objRepond 등의 변수명은 기계적으로 해석하기에는 더 적당할지 몰라도

어떤 용도로 누가 사용하지는지에 대한 의미는 내포하지 않습니다.

그래서 저는 가능하다면

descriptionTitle, currentIndex, respondingData 등으로 풀어씁니다.

함수명도 길어지는 한이 있더라도

CustomMenu, CustomItem 보다는

CustomContextMenu, CustomContextMenuItem 등으로 풀어서 쓰는게 더 이해하기 쉽다고 생각합니다.

그렇다면 여기서 잠깐 !!

변수명의 길이와 퍼포먼스와는 상관이 없을까요?
 
2005년도였나? 앙드레 미쉘이 Macromedia에 질문을 했답니다.
 
변수명은 어차피 메모리주소로 치환되니 퍼포먼스와는 상관이 없는것이냐?
 
뭐라고 대답이 왔는지는 기억이 안나는데
 
앙드레형님은 대답이 시원찮아서 직접 테스트를 해보았답니다.
 
결과는...
 
...
 
...
 
...
 
상관이 있더랍니다.
 
예전 xPrime의 정윤수과장님이 여쭤보셔서 그자리에서

앙드레 형이 한것과 비슷한 테스트를 한적이 있었는데
 
좀 어처구니 없었습니다.
 
상식을 뒤엎는 결과였다고 할까요?
  

테스트코드 보기


위 테스트코드에서 나오다시피 아주 적은 차이라지만

(변수명이 너무 길었는지 테이블에서도 짤리네효 >.<)

분명 퍼포먼스에 영향을 미치는 결과임을 알 수 있습니다.

실로 놀라움을 금치 않을 수 없었습니다.

하지만 저정도 퍼포먼스는 생산성을 위한 가독성에 양보해도 되겠다라는게 제 주장입니다. ㅋㄷ

사실 전혀 생각도 못했었습니다.

변수명의 길이와 퍼포먼스가 관계가 있을 줄은...

저의 코드 스타일 선생님이기도 하고 정말 주옥같은 코드로 절 좌절시킨...

앙드레형...





3. 직렬관계의 메소드들은 Prefix(접두어)를 사용한다.

직렬관계가 뭐냐면 

public function load(): void
{
     this.readData( Data.getData() );
}

private function readData( data: Data ): void
{
     var integrated: Boolean = data.integrationCheck();
    
     if( ! integrated )
          return;
    
     this.parseComplete();
}

private function parseComplete(): void
{
    
}

위에서 load() 함수 마지막에 readData()이 호출되고 readData() 함수 마지막에는 parseComplete()가 호출됩니다. 

이렇게 꼬리에 꼬리를 물고 함수가 이어지는 관계를 직렬관계라고 합니다.

이러한 일련의 직렬관계인 메소드들은

Prefix(접미어)를 이용해서 아래와 같이 네이밍을 합니다.

public function load(): void
{
     this.loadData( Data.getData() );
}

private function loadData( data: Data ): void
{
     var integrated: Boolean = data.integrationCheck();
    
     if( ! integrated )
          return;
    
     this.loadDataParseComplete();
}

private function loadDataParseComplete(): void
{
    
}

이렇게 공통어로 직렬관계의 메소드나 변수명을 지어놓을 경우

여러가지로 장점이 있습니다.

 - Code Assist 할때 load 라고 까지만 입력하면 

연관된 메소드들이 나타납니다. 

화살키로 바로 선택해서 쓰면 매우 편리합니다.

 - 하나의 프로세스를 prefix로 묶어줌으로써

코드의 가독성을 높이고 오래 지나더라도 이해하기가 쉽습니다.

 - 메소드의 역할을 체계적으로 분리함으로써 하나의 함수가 하나의 역할만하는

SRP(Single-Responsible Principle) 을 유지할 수 있습니다.

손에 익으면 매우 편리할 것입니다.^^





IDE가 아무리 발전해도 도와줄 수 없는 부분중에 하나가

바로 Naming이 아닌가 합니다.

잘 지은 함수명 하나 열 알고리즘 안부럽다. (좀 심했나 ㅋ)

아무튼 네이밍은 10년이 지나도 어려울 것 같고 

20년이 지나도 영어사전을 옆구리에 끼고 살거 같습니다.

고수들의 코드를 보면

알고리즘이나 아키텍쳐도 볼만하지만

특히나 전 네이밍을 유심히 보는 편입니다.

뭐니 뭐니해도 네이밍의 Best-Practice는 F1이 아닐까 합니다.

클래스명이나 함수명뿐만이 아니더라도

도움말의 챕터명이나 문서명, 각 문단의 타이틀들도 

정말 간결하고 필요한 뜻만 딱딱 내포하고 있습니다.

(그러면서 가끔 오타내주는 센스~)



코드의 완성은

더 이상 추가할게 없을때가 아니라

더 이상 걷어낼게 없을때가 아닐까 합니다.

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. 이동근 2008.10.27 17:48 신고

    재밌게 읽었습니다. 항상 고민이 되는 문제네요.

  2. Favicon of http://hangunsworld.com Han Sanghun 2008.10.27 23:45 신고

    http://www.simonwacker.com/weblog/2005/04/12/actionscript-2-coding-standards-the-method/
    이것도 참고해서 볼만...

  3. Favicon of http://www.jinhokim.com 찌노 2008.10.28 09:30 신고

    님 좀 짱인듯! ㅎ

  4. 금도리 2008.10.28 11:44 신고

    콩굴리쉬를 고쳐야것군여..하하하...

  5. 아르모르 2008.10.29 18:06 신고

    또 좋은글 잘 읽었습니다... 저도 항상 사전을 끼고 살지만...어려운건 사실이에요..
    하지만 그런고민들이 발전을 만들겠죠? 라고 긍정적인 생각으로 ~~ ㅎㅎ

    끝에 말 정말 명언인데요~~ +0+

    • Favicon of http://wooyaggo.tistory.com 우야꼬  2008.10.29 23:22 신고

      "실용주의 프로그래머"에서 나오는
      '소프트웨어의 완성은 기능을 더 이상 추가할 수 없을 때가 아니라
      기능을 더 이상 빼낼게 없을 때다.'
      라는 말을 맘대로 바꿔봤습니다. ㅎㅎ

  6. Favicon of http://hangunsworld.com Han Sanghun 2008.10.29 22:17 신고

    콜린무크 책에 보면 이런 얘기가 있지.
    Well-named methods are effectively self-commenting.

    • Favicon of http://wooyaggo.tistory.com 우야꼬  2008.10.29 23:21 신고

      맞아요.
      메소드명만 보고도 무슨 역할을 하는지 알 수 있어야하고
      메소드명대로만 정확하게 동작해야하는... 그런 ㅎㅎ
      아 어렵다 어려워 ㅋㅋ

  7. Favicon of http://blog.naver.com/setimets 쫑쫑쫑 2008.11.01 02:31 신고

    네이밍 하다가 맥이 끊어지는 .... 좋은 글 잘보고 갑니다 ^-^

  8. Favicon of http://warkyman.tistory.com 검쉰 2008.11.01 22:48 신고

    매번 느끼는 거지만 네이밍 정말 중요하고 어렵습니다. ^^;

  9. 니우 2008.12.31 04:21 신고

    진짜 저렇게 보니깐 제가 지은 함수들은 항상 헷갈린 이유를 알겠네요
    좋으내용 잘 봤습니다 감사해요~

  10. Favicon of http://desigrammer.tistory.com chofa 2009.03.22 14:42 신고

    저도 네이밍 하나에.. 5분 고민하는 듯 .. ^^;;;;
    좋은글 잘봤습니다^^

  11. soma 2009.05.15 15:18 신고

    정말 잘 봤습니다.^^
    끝에 쓰신 말씀을 세미나에 좀 인용 했는데 괜찮을런지요?? ^^;;

    • Favicon of http://wooyaggo.tistory.com 우야꼬  2009.05.17 02:49 신고

      저야 감사할 따름입니다.
      블로그의 올리는 이유가 "공유"말고 또 있겠습니까^^
      저도 다른 분들이 도움이 되셨으면하는 마음에 올리는거고
      soma님 처럼 세미나를 통해서 더 많은 분들에게 도움이 되는 수단으로 사용하신다는데
      그보다 더 뿌듯한게 어딨겠습니까^^

  12. Favicon of http://blog.jidolstar.com 지돌스타 2009.10.27 10:16 신고

    멋진글!

  13. Favicon of http://desty.kr desty 2009.10.27 21:46 신고

    영어 사전과 레퍼런스 사전은 개발자의 필수 ?!

  14. 믹네코이 2010.01.22 14:42 신고

    전 그래서 네이밍 할때마다 네이버에서 검색해서 쓴다는 -0-;;;
    그보다 변수명같은게 길면 느려진다니 이건 좀 충격인데요...;ㅁ;

  15. 영희 2010.05.18 10:39 신고

    저도 2007년 겨울 야꼬형의 세미나를 듣고 코딩스타일 바뀌었는데....
    3번.... 공백은ㅋ;; 같이 일할때 혼났던 기억이 있네요~
    지금은 백스페이스바가아닌 컨트롤 + D키를 이용해서 공백이 없어요^^;;;
    직렬관계 메소드 접두어사용은 버릇처럼 사용해야 겠네요~~~

  16. Favicon of http://xoul.kr 소울 2010.08.06 22:58 신고

    잘봤습니다!

+ Recent posts