E D R , A S I H C RSS

가�성

간단하게 C언어� 대한 문제와 답� 올리는 페�지�서 다�과 같� 내용� 있었다.

~cpp 
※ 다�� 옳�지 옳지 않�지 �가하고 옳다면 옳다고 �고, 옳지 않으면 옳지 않다고 �고 왜 그런지 �유를 �으시오.

1.

#include <stdio.h> 
 
main(){ 
int i; 
 
        for(i=0; i<10; i++){    // 딴지 : {는 for문 뒤� 쓰는 것� 좋다. -_-. 내리는 것� 정� 좋지 않� 스타��다.(가�성� 해친다.) 
                printf("%d", i); 
        } 
} 

brace를 같� 줄� 쓰는 것� 과연 가�성� 해치는가?

ê°€ë�…성ì�€ ê°œì�¸ì·¨í–¥ì�´ë�¼ê³  ìƒ�ê°�합니다. ì œ 경우는 C, C++ì—�서 { 를 내리지 않는 경우보단 내리는 경우가 ë�” 보기 편하고, JavaLanguage ì—�서는 내리지 않는게 ë�” 편하답니다. ì• ì´ˆì—� CodingConventions ì�´ë�¼ëŠ” 것ì�´ 존재하는 것ë�„ 통ì�¼ë�œ 코딩규칙ì�„ 따르지 않고 ê°œì�¸ì·¨í–¥ì�˜ 코드를 만들어내다 ë³´ë©´ ì „ì²´ì �으로 코드ì�˜ 융통성ì�´ ê²°ì—¬ë�˜ê³  ê°€ë�…성ë˜�한 ì „ì²´ì �으로 떨어지는 문제를 미연ì—� 방지하기 위함ì�´ë�¼ê³  ìƒ�ê°�합니다. 특히나 ExtremeProgramming ì�˜ 경우처럼 CollectiveOwnership ì�„ 중요한 프랙티스 중ì�˜ 하나로 규정한 방법론ì—�서는 CodingConventions ê³¼ ê°™ì�€ ê³µë�™ì†Œìœ ì�˜ ì‚°ìœë¬¼ì—� 대한 규칙ì�´ ë�”윽 중요하다고 ìƒ�ê°�ë�©ë‹ˆë‹¤. 요는, { 를 내리ëŠ�ëƒ� 내리지 않ëŠ�ëƒ�ê°€ ê°€ë�…성ì�´ 높ëƒ� ë‚®ëƒ�를 결정짓는 것ì�´ 아니고 ê°€ë�…성ì�´ë�¼ëŠ” 하나ì�˜ í�‰ê°€ìš”소ì�˜ 가치는 ê°œì�¸ì—� ë”°ë�¼ 달ë�¼ì§ˆ 수 있다는 것입니다. - ìž„ì�¸íƒ�

ì�´ 글ì�„ ì“°ê³  ì € 문제ì—� 대한 ì�´ì�˜ 제기가 들어올줄 예ìƒ�ì�€ 하고 있었습니다. ê·¸ì—� 따른 ì œ 변명ì�€ ì�´ë ‡ìŠµë‹ˆë‹¤. 여러 언어ì�˜ 특성ìƒ� 언어마다ì�˜ 코딩 스타ì�¼ì�€ 엄연히 존재합니다. C언어ì�˜ 특성ì—� ë”°ë�¼ 하나ì�˜ 함수는 한 화면ì—� 모ë‘� ìœë ¥ë�˜ê²Œ 하는 것ì�´ 중요합니다. (물론 요즘과 ê°™ì�€ í�° 터미ë„�ì—�서는 문제가 ë�˜ì§€ 않겠습니다만,..) 때문ì—� 코드ì�˜ ê°€ë�…성ì�„ 높히며 ë§Žì�€ 코드들ì�„ 짜는 것ì�€ 불가분ì�˜ 관계ë�¼ê³ ë�„ í•  수 있겠죠.(함수를 붙여쓰면 코드들ì�€ ë§Žì�´ 들어가나 ê°€ë�…성ì�´ 매우 떨어지죠.) 하지만 C언어ì—�서 저것과 ê°™ì�€ ë°©ì‹�ì�˜ 코드는 코드ì�˜ ë�¼ì�¸ë§Œ 늘리는 결과를 초래하게 ë�©ë‹ˆë‹¤. 예를 들어 24ë�¼ì�¸ë§Œ 쓸 수 있는ë�° for문과 while문ì�˜ 갯수가 4ê°œë�¼ê³  하면 4줄ì�„ 낭비하는 ê¼´ì�´ ë�©ë‹ˆë‹¤. 즉, for문과 while문ì�˜ ê°€ë�…성ì�„ 위해 ì „ì²´ì �ì�¸ 함수 ê°€ë�…성ì�„ 떨어뜨리게 ë�˜ëŠ” 것ì�´ì£ . (ë˜�한 for문과 while문ì�˜ {를 아래로 내리는 것과 위로 올리는 것ì�˜ ì°¨ì�´ì �ì�€ 얼마ë�˜ì§€ 않습니다.) 제가 강조한 것ì�€ ì�´ ì „ì²´ì �ì�¸ 모듈ì�˜ ê°€ë�…성ì�„ 뜻한 것입니다. (딴지를 걸ìž�ë©´ 80x24 화면ì—� 저러한 코딩 ë°©ì‹�ì�„ 사용하는 것ì�€ 죽ì�Œì�„ ìž�초하는 길ì�¼ê²ƒìž…니다. 토발즈 ë˜�한 강조한 것ì�´ê¸°ë�„ 하구요. :) ) - ì�´ì˜�호
저� 중괄호({,brace)를 한줄� 쓰는 스타�� 선호합니다. 하지만 그것� 어디까지나 취향� 문제�고 ��합니다. 취향� 약간 다를 ��지 (과장� 표현�었겠지만) 죽�� �초할 정�로 틀린�� 아니�고 ��합니다. �만한 CollectiveOwnership � 위해서는 다른것� 틀리다고 �하면 안�것 같습니다. --��준

Python 과 같� 언어� 경우 {} �체를 쓰지 않고 아� 들여쓰기로 블�를 표현합니다. 우리가 코드를 볼때 해당 블� 범위를 ��때�는 { } � 위치보다는 들여쓰기로 블� 범위를 파악하는 �� � 많다는 �� 대해서� ��해 볼 필요가 있� 것 같습니다. --1002


글� 작성하신 분과 제가 ��하는 '가�성'� 대한 정�가 다른게 아닌가 합니다. 코드를 글로 비유해 보�면(저는 비유나 �유를 좋아한답니다) ��호님께서는 눈� 거슬리지 않게 전체�� 문장� 한눈� 들어오는가를 중요하게 ��하시는 것 같습니다. 저는 가�성��는 개�� 문장들� 얼마나 매�럽고 문단과 문단� 연결� 부�절함� 없는가� 초�� 맞추고 있습니다. 문단� 첫 글�를 들여쓰기를 하�� 마��가 중요한 것� 아니고 그 문단� 주제를 얼마나 명확하고 깔�하게 전달해 주��가 중요하다는 것�죠. CollectiveOwnership � 위한 CodingConventions와 글쓰기를 연계시켜 ��해 보�면 하오체를 쓸것�가 해요체를 쓸것�가 정해�� 정�가 �까요? 제가 ��하는 가�성� 정��서 brace� 위치는 지엽�� 문제입니다. SeeAlso Seminar:국어실력과프로그래�
저� 딴지를 약간 걸어보�면 토발즈가 작성한 Linux Kernel Coding Style ��는 문서를 보니 첫 부분� 다�과 같� 부분� 있네요.
{{|
This is a short document describing the preferred coding style for the linux kernel. Coding style is very personal, and I won't force my views on anybody, but this is what goes for anything that I have to be able to maintain, and I'd prefer it for most other things too. Please at least consider the points made here.
|}}
위� 서문(?)과 brace� 대한 부분� �� 토발즈가 코딩 스타�� 대한 �신� ��� ��들�게 강조한 것으로는 보�지 않네요. - 임��

같� 코드� 가�성� 작업 환경� 따� 달�지는가?

위�서 �야기한 것 중 터미� 화면�서� 작업시 세로��� 범위가 �� 경우 { } 가 가�성� 해칠수 있다는 �견� 있습니다. 재미있는 �견 같네요.

전� 여러 회사� 팀들 분들과 �야기를 하면 사람들마다 얼마나 취향차들� 다른가� 대해서 ��는�, 한편으로는 그냥 개�� 취향차로만 보기�는 그 분들� 작업 환경� 따� 차�가 있는 듯 합니다. �례로, Refactoring 개�� 개발�들�게 �진 �후 메소드는 가능한 한 짧고 간결하며 한가지 기능만� 하는게 가�성과 모듈디��� 좋다고 �야기합니다. 근�, 리눅스나 VI �서 작업하시는 분들� '너무 메소드 길�가 짧아� 안좋다.' ��지 '리눅스� xx 코드 본 � 있�? 한페�지� 주욱 나오는게 정� �기가 좋다.' 'OO 디��� 좋다고 하는�, 코드 분�하려면 � 화� 저 화� �아다니고 메소드들� �리저리 �아다녀야 하고 별로 안좋�거 같다' �고 �씀하시는 분들� 있습니다.

그래서 추측� 했었는�, �신� 쓰는 �구� 따� 같� 코드� 가�성� �향� 받� 수 있겠다는 ��� 해봅니다. VI 등� editor 들로 코드를 보는 분들��면 아마 �반 문서처럼 주욱 있는 코드들� navigation 하기 편합니다. (아마 jkl; 로 �아다니거나 ctrl+n 으로 page 단위로 ��하시는 등) �러한 경우 OO 코드를 분�하려면 �화� 저화� �디터� �워야 하는 화�들� 많아지고, ��하기 불편하게 �니다. (물론 ctags 를 쓰는 사람들� � 코드 분�법� 다르겠죠) 하지만 Eclipse 를 쓰는 사람��면 코드 분�시 outliner 와 caller & callee 를 �서 코드를 분�하고 navigation 할 �니다. �런 분들� 경우 �래스들과 메소드들� 잘게 나누어져 있어� 차�리 메소드� �미들� 잘 분리�어있는게 분�하기 좋죠.

가�성� ��할때 종종 �런 ��� 합니다. '어떠한 코드가 디��� 좋�가? 혹� 어떠한 �구가 좋� 디��� ��게 하는� �움� 주는가?' 어떻게든 �구를 만들고, 다시 �구� �향� 받게 �는게 사람�니까요. --1002




Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:28:38
Processing time 0.0102 sec