코딩 스타일의 상식을 박살 내라
서두
엔지니어 여러분은 평상시 다양한 상식에 사로 잡히고 있지 않습니까? 그러한 상식의 상당수는 믿음이며 당신의 능력이나 생산성을 방해하는 요인이 되고 있습니다. 이 연재에서는 고정 관념을 깨어, 유저 시점에서 고품질의 일을 해내는 「리얼 엔지니어」으로 한 걸음을 내디디는 아이디어 여러 가지를 소개합니다.
빠져 나가라! 영문법의 속박
베테랑일수록 「그래, 이러한 것」적인 미를 고집하는 것 같습니다.
예를 들면 프로그램 언어는 영어를 기조로 하고 있습니다.「영문법을 의식하는 것이 아름답다. 왜냐하면 그러한 것이니까」라고 하는 것은 그 대표 예입니다.
우선 이 예를 봐 주세요. 직감적으로 어느 쪽이 아름다운지 아이와 같은 깨끗한 마음으로 봐 주세요.
예 A
TopMargin = 10;
BottomMargin = 10;
LeftMargin = 20;
RightMargin = 20;
예 B
MarginTop = 10;
MarginBottom = 10;
MarginLeft = 20;
MarginRight =20;
예 A는 영문법에 따른 기술, 예 B는 Margin을 앞으로 기술했습니다.
어떻습니까?
영문법을 무시한 예 B쪽이 「Margin」이 깨끗하게 갖추어져 있어 아름답지 않습니까. 여기까지 깨끗하게 모이면 대입 부분 「
= 10;
」도 정리하고 싶어집니다.
예 C
MarginTop = 10;
MarginBottom = 10;
MarginLeft = 20;
MarginRight = 20;
한층 더 아름다워졌습니다. 소스의 시인성(視認性)이 올라서 유지보수도 편하게 되겠죠.
보충
최근에는 클래스로 설계하므로,
Margin->Top = 10;
라고 기술하는 것이 많습니다만 네이밍이라고 하는 시점에서 읽어 주세요.
상식에 속박 되고 있지 않습니까? 「있어야 아름다운 모습」이라고 생각하고 있는 것은 정말로 아름답습니까?
훌륭한 멀티 스테이트먼트의 세계!
「멀티 스테이트먼트」. 이 단어를 알고 있는 분, 기억하고 있는 분, 어느 정도 계십니까? 80년대 전반 주로 interpreter 언어에 있어서 유행된 기술 방법입니다.
멀티 스테이트먼트란
지금은
a=10;
b=20;
c=a+b;
이라고 쓰는 것을
a=10; b=20; c=a+b;
와 같이 쓰는 것이 멀티 스테이트먼트입니다. 1행에 복수의 명령을 기술하는 매우 기분 나쁜 기술 방법입니다.
그렇지만 옛날에는 제대로 의미가 있었습니다. 아직 컴퓨터가 빈약했던 시대 멀티 스테이트먼트로 기술하는 것으로
조금 메모리가 절약
좀 더 처리 스피드가 오른
닙다.
그 후 컴퓨터 기술의 발달에 의해 멀티 스테이트먼트는 그 의미를 잃었습니다…….
부활! 현대풍 멀티 스테이트먼트!
우선 다음의 소스를 봐 주세요. 월 마다 대입 문자열을 바꾸는 처리로 비교적 알기 쉬운 소스입니다.
switch(month){
case 1:
tsuki="1월";
koyomi="1월";
break;
case 2:
tsuki="2월";
koyomi="2월";
break;
case 3:
tsuki="3월";
koyomi="3월";
break;
case 4:
tsuki="4월";
koyomi="4월";
break;
case 5:
tsuki="5월";
koyomi="5월";
break;
case 6:
tsuki="6월";
koyomi="6월";
break;
case 7:
tsuki="7월";
koyomi="7월";
break;
case 8:
tsuki="8월";
koyomi="8월";
break;
case 9:
tsuki="9월";
koyomi="9월";
break;
case 10:
tsuki="10월";
koyomi="10월";
break;
case 11:
tsuki="11월";
koyomi="11월";
break;
case 12:
tsuki="12월";
koyomi="12월";
break;
default:
tsuki="";
koyomi="";
break;
}
이것을 현대풍 멀티 스테이트먼트로 기술해 봅시다!
switch(month){
case 1: tsuki= "1월"; koyomi= "1월"; break;
case 2: tsuki= "2월"; koyomi= "2월"; break;
case 3: tsuki= "3월"; koyomi= "3월"; break;
case 4: tsuki= "4월"; koyomi= "4월"; break;
case 5: tsuki= "5월"; koyomi= "5월"; break;
case 6: tsuki= "6월"; koyomi="6월"; break;
case 7: tsuki= "7월"; koyomi= "7월"; break;
case 8: tsuki= "8월"; koyomi= "8월"; break;
case 9: tsuki= "9월"; koyomi= "9월"; break;
case 10: tsuki= "10월"; koyomi="10월"; break;
case 11: tsuki="11월"; koyomi= "11월"; break;
case 12: tsuki="12월"; koyomi= "12월"; break;
default: tsuki= ""; koyomi= ""; break;
}
이렇게 되었습니다. 실로 컴팩트하고 시인성 좋게 되었습니다.
필자가 이것을 실천했을 때 「 어째서 멀티 스테이트먼트야!」라고 많은 물의를 일으킵니다. 이미 먼 과거의 것으로 여겨진 기술법을 꺼냈으니까 비판되는 것도 당연하다고 말하면 당연합니다. 그러나 한 번 이것에 익숙한 사람은 그만둘 수 없게 됩니다.
한번 더, 잘 봐 주세요.
각 case에 대응하는 처리가 세로에 깨끗이 줄서 한눈에 확인할 수 있습니다. 부주의 BUG 혼입을 막을 수 있기 때문에 유지보수 성이 올르고 또 소스도 컴팩트하게 되기 때문에 좋습니다.
만약 「아니! 그것은 이상하다!」라고 반론하고 싶어졌다고 하면 그것은 당신이 열중한 상식에 붙잡혀 있는 탓인지도 모릅니다.
"박살 내라 상식! 리얼 엔지니어의 길" 이만 마칩니다.
주
예의 단순한 반복이 계속 되는 경우에 유효합니다. 복잡한 처리를 무리하게 멀티 스테이트먼트로 하는 것은 전혀 추천하지 않습니다.
'생각하는개발 > 코딩스타일' 카테고리의 다른 글
헝가리안 표기법 (코딩표준) - 2 (0) | 2010.08.22 |
---|---|
헝가리안 표기법 (코딩표준) (0) | 2010.08.22 |