코딩 스타일의 상식을 박살내라

코딩 스타일의 상식을 박살 내라

 

서두

엔지니어 여러분은 평상시 다양한 상식에 사로 잡히고 있지 않습니까? 그러한 상식의 상당수는 믿음이며 당신의 능력이나 생산성을 방해하는 요인이 되고 있습니다. 이 연재에서는 고정 관념을 깨어, 유저 시점에서 고품질의 일을 해내는 「리얼 엔지니어」으로 한 걸음을 내디디는 아이디어 여러 가지를 소개합니다.

빠져 나가라! 영문법의 속박

베테랑일수록 「그래, 이러한 것」적인 미를 고집하는 것 같습니다.

예를 들면 프로그램 언어는 영어를 기조로 하고 있습니다.「영문법을 의식하는 것이 아름답다. 왜냐하면 그러한 것이니까」라고 하는 것은 그 대표 예입니다.

우선 이 예를 봐 주세요. 직감적으로 어느 쪽이 아름다운지 아이와 같은 깨끗한 마음으로 봐 주세요.

 

예 A

1. TopMargin = 10;

2. BottomMargin = 10;

3. LeftMargin = 20;

4. RightMargin = 20;

 

예 B

1. MarginTop = 10;

2. MarginBottom = 10;

3. MarginLeft = 20;

4. MarginRight =20;

 

예 A는 영문법에 따른 기술, 예 B는 Margin을 앞으로 기술했습니다.

어떻습니까?

영문법을 무시한 예 B쪽이 「Margin」이 깨끗하게 갖추어져 있어 아름답지 않습니까. 여기까지 깨끗하게 모이면 대입 부분 「
= 10;
」도 정리하고 싶어집니다.

 

예 C

1. MarginTop    = 10;

2. MarginBottom = 10;

3. MarginLeft   = 20;

4. MarginRight  = 20;

 

한층 더 아름다워졌습니다. 소스의 시인성(視認性)이 올라서 유지보수도 편하게 되겠죠.

 

보충

최근에는 클래스로 설계하므로,

Margin->Top = 10;

라고 기술하는 것이 많습니다만 네이밍이라고 하는 시점에서 읽어 주세요.

 

상식에 속박 되고 있지 않습니까? 「있어야 아름다운 모습」이라고 생각하고 있는 것은 정말로 아름답습니까?

 

훌륭한 멀티 스테이트먼트의 세계!

「멀티 스테이트먼트」. 이 단어를 알고 있는 분, 기억하고 있는 분, 어느 정도 계십니까?  80년대 전반 주로 interpreter 언어에 있어서 유행된 기술 방법입니다.

 

멀티 스테이트먼트란

지금은

1. a=10;

2. b=20;

3. c=a+b;

4.  

 

이라고 쓰는 것을

1. a=10; b=20; c=a+b;

 

와 같이 쓰는 것이 멀티 스테이트먼트입니다. 1행에  복수의 명령을 기술하는 매우 기분 나쁜 기술 방법입니다.

그렇지만 옛날에는 제대로 의미가 있었습니다. 아직 컴퓨터가 빈약했던 시대 멀티 스테이트먼트로 기술하는 것으로

  조금 메모리가 절약

  좀 더 처리 스피드가 오른

닙다.

그 후 컴퓨터 기술의 발달에 의해 멀티 스테이트먼트는 그 의미를 잃었습니다…….

 

부활! 현대풍 멀티 스테이트먼트!

우선 다음의 소스를 봐 주세요. 월 마다 대입 문자열을 바꾸는 처리로 비교적 알기 쉬운 소스입니다.

 

1. switch(month){

2.     case 1:

3.        tsuki="1월";

4.        koyomi="1월";

5.        break;

6. 
   

7.     case 2:

8.        tsuki="2월";

9.        koyomi="2월";

10.        break;

11. 
    

12.     case 3:

13.        tsuki="3월";

14.        koyomi="3월";

15.        break;

16. 
    

17.     case 4:

18.        tsuki="4월";

19.        koyomi="4월";

20.        break;

21. 
    

22.     case 5:

23.        tsuki="5월";

24.        koyomi="5월";

25.        break;

26. 
    

27.     case 6:

28.        tsuki="6월";

29.        koyomi="6월";

30.        break;

31. 
    

32.     case 7:

33.        tsuki="7월";

34.        koyomi="7월";

35.        break;

36. 
    

37.     case 8:

38.        tsuki="8월";

39.        koyomi="8월";

40.        break;

41. 
    

42.     case 9:

43.        tsuki="9월";

44.        koyomi="9월";

45.        break;

46. 
    

47.     case 10:

48.        tsuki="10월";

49.        koyomi="10월";

50.        break;

51. 
    

52.     case 11:

53.        tsuki="11월";

54.        koyomi="11월";

55.        break;

56. 
    

57.     case 12:

58.        tsuki="12월";

59.        koyomi="12월";

60.        break;

61. 
    

62.     default:

63.        tsuki="";

64.        koyomi="";

65.        break;

66. }

 

이것을 현대풍 멀티 스테이트먼트로 기술해 봅시다!

1. switch(month){

2. case 1: tsuki= "1월"; koyomi= "1월"; break;

3. case 2: tsuki= "2월"; koyomi= "2월"; break;

4. case 3: tsuki= "3월"; koyomi= "3월"; break;

5. case 4: tsuki= "4월"; koyomi= "4월"; break;

6. case 5: tsuki= "5월"; koyomi= "5월"; break;

7. case 6: tsuki= "6월"; koyomi="6월"; break;

8. case 7: tsuki= "7월"; koyomi= "7월"; break;

9. case 8: tsuki= "8월"; koyomi= "8월"; break;

10. case 9: tsuki= "9월"; koyomi= "9월"; break;

11. case 10: tsuki= "10월"; koyomi="10월"; break;

12. case 11: tsuki="11월"; koyomi= "11월"; break;

13. case 12: tsuki="12월"; koyomi= "12월"; break;

14. default: tsuki= ""; koyomi= ""; break;

15. }

 

이렇게 되었습니다. 실로 컴팩트하고 시인성 좋게 되었습니다.

필자가 이것을 실천했을 때 「 어째서 멀티 스테이트먼트야!」라고 많은 물의를 일으킵니다. 이미 먼 과거의 것으로 여겨진 기술법을 꺼냈으니까 비판되는 것도 당연하다고 말하면 당연합니다. 그러나 한 번 이것에 익숙한 사람은 그만둘 수 없게 됩니다.

한번 더, 잘 봐 주세요.

 

각 case에 대응하는 처리가 세로에 깨끗이 줄서 한눈에 확인할 수 있습니다. 부주의 BUG 혼입을 막을 수 있기 때문에 유지보수 성이 올르고 또 소스도 컴팩트하게 되기 때문에 좋습니다.

 

만약 「아니! 그것은 이상하다!」라고 반론하고 싶어졌다고 하면 그것은 당신이 열중한 상식에 붙잡혀 있는 탓인지도 모릅니다.

 

"박살 내라 상식! 리얼 엔지니어의 길" 이만 마칩니다.

 

주

　예의 단순한 반복이 계속 되는 경우에 유효합니다. 복잡한 처리를 무리하게 멀티 스테이트먼트로 하는 것은 전혀 추천하지 않습니다.