[AS3] 네이밍과 코드 스타일

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

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

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

말 그대로 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의 정윤수과장님이 여쭤보셔서 그자리에서

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

package {      import flash.display.Sprite;      import flash.events.Event;      import flash.events.MouseEvent;      import flash.utils.getTimer;      public class Sample extends Sprite      {           public function Sample()           {                this.stage.addEventListener( MouseEvent.CLICK, start );           }                     private function start( e: Event ): void           {                const length: int = 100000000;                var i: int = 0;                var time: int = 0;                var tmp: int;                var shortValue: int = 2;                var veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongValue: int = 2;                               i = length;                time = getTimer();                               while( i -- )                {                     tmp = shortValue;                }                               trace( getTimer() - time );          // 1205                               i = length;                time = getTimer();                               while( i-- )                {                     tmp = veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongValue;                }                               trace( getTimer() - time );          // 1368           }      } }

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

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

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

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

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

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

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

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

앙드레형...

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이 아닐까 합니다.

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

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

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

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

코드의 완성은

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

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