스스로 보기에 가독성 좋은 코드의 예를 비교해 보여주세요.
관련글 http://kldp.org/node/124302
< 배경 >
대부분의 어떤 이론이나 실험, 수식들은 어떤 가정하에서 성립하지요. 그래서 그런 논제에 관해 논의를 할때는 제시된 가정하에 검토되어야 할거에요. 하지만 이런 논의에 준비되지 않은 우월한 참여자들은 논제의 검토보다는 가정의 불합리성만을 지적하기 위해 참여하는 경우가 흔한데요. 그래서 편파적인 참여자들은 발제자를 우매하게 보이도록 의도적으로 논제의 가정을 빈정거리기도 해요. 뭐가 되었든, 이런 성의없는 참여는 결과적으로 성숙한 논의의 진행을 방해하기 마련이죠.
논의의 진행을 방해하는 그런 생각짧은 참여들을 사전에 방지하고자, "가독성을 고려하지 말아달라"고 분명히 명시하였지만, Winner님 외에 다들 일단 가정부터 부정하고 보는건 여전하시네요. (수준낮은 조직은 어리석었던 역사를 알고도 반복하는 게 현실이지만요.)
< 논제를 벗어난 답글들에게 >
제가 "용량" 줄이기라고 표현한 것은 "짧은" 소스코드에 대한 수사적(Rhetoric) 표현이에요. "짧다"는 표현은 2차원으로 고려될 수도 있기 때문에, 혹시나 "가로는 긴데?" 이런분 계실까봐, 1차원인 "용량"으로 표현한 것 뿐이고요. 코딩 입문자도 아니시면서, zip파일이라니요.. --;
ioccc 찾아보시라 하신분은 (짧은===읽기 어려운) 으로 알고 계신가봐요. 안쪽팔리세요? --;
짧게 쓰는 소스코드를 부정하고 보는 분들의 성급한 착각은 병신같은 ioccc처럼 코드 "전체"를 "읽기 어려울 만큼" 짧게만 쓰려고 한다는 점과 짧은 코드가 "항상" 가독성을 나쁘게 한다는 점인듯 싶어요.
그리 판단하셨다면 그것은 이 논의에 임하는 생각이 짧으시거나, 논제의 가정을 빈정거리기위한 참여로만 보여요. 어떤 익명분의 "단 한개도 좋아보이는게 없다" 라는 표현에서 조롱,빈정,업신여김 등등이 느껴지고요. (이글 마지막 문단에서 본인의 우월함을 입증할 기회를 드리니 비슷한 자세로 참여해주세요.)
코드를 하다보면 짧게 써야할 때도 있고, 장황하게 써야하는 때도 있겠지요. 짧게 쓰는 요령을 여쭐 때는 짧게 써야만 하는 상황이나 짧은 코드가 이득인 경우만을 생각하시면 되는거에요. 그리고 어떤 편집기의 기능이 짧은 코드와 정상 코드로 양방향 변환을 지원한다고 생각해 보세요. 양방향 변환이 되기 때문에 개인 편차에 따른 우려는 없는 셈이지요. 이런 기능을 구현하기 위해 여쭙는 논의일 수도 있는건데, 그저 "짧게 쓰는게 바보짓이다"라고 지적부터 하고 본다면, 누구 생각이 더 짧은건지 여쭙고 싶어요.
가독성은 개인편차가 크기 때문에 논의하려하지 않았지만, 짧은 코드가 항상 읽기 어렵다고 주장하신다해도 그건 본인 사정이라고 말씀드리고 싶어요.
제 경우를 말씀드리면요, 페이지 스크롤 없이 읽을 수 있는 코드가 가장 좋다고 생각해요. 그런 점에서 코드 형태와 무관하게 세로뱡항 모니터가 더 읽기 유리하지요. 그래서 제 코딩은 세워놓은 모니터에서 주로 해요. 어떤 한 함수가 몇 페이지 걸쳐 있었다면 스크롤동안 읽던 위치를 다시 찾으려고 눈알을 굴리기가 오히려 더 읽기 힘들게 만들거든요.
함수들이 이미 짧고, 이미 잘 동작하는 함수들을 다시 읽어야 경우도 별로 없지요.
일부러 몇 페이지에 걸쳐 함수를 만드는 것도 현명하지 못한것 같아요. 여러줄에 걸친 1개 인스트럭션이나 좌우스크롤도 읽기 나쁜 건 마찬가지고요. 정말 긴 이름이 필요하다면 선언지역에서 별도로 주석을 달면 되기 때문에, 코드내에서까지 일일이 긴 이름을 사용하는것도 그리 생산적으로 보이지 않네요. 중요한건 함수호출표현이 얼마나 직관적인가가 아닌가 싶어요. 인덴트만 지키면 구조 파악하는데 문제가 없고요. 사용하는 편집기가 구분되는 색상을 지원하기 때문에 공백이 없어도 사실 별 지장이 없어요.
아래 예중 어느 것이 읽기 좋으세요?
local_string := IntegerToString ( StringToInteger ( local_String ) + local_integer ); // 자연어로 읽어지는 기준으로 만든 함수명 s := s_i( i_s(s)+i ); // 데이터타입과 방향을 기준으로 만들어진 함수명
성의있는 답변을 기다리기위해 관련없는 답들에는 일일이 대응하지 않았는데요. 아무래도 짧게 쓰는 코드보다는 가독성에 더 관심들이 많은것 같아서 짧게 쓴 코드의 가독성이 항상 바보짓같이 열등한지 입증할 기회를 드리고자 새 멍석을 깔아드릴께요. 부디 이전 글타래에는 짧게 쓰기 위한 의견만 남기시기 바라고요. 우월한 가독성에 대한 의견은 이곳에 남겨주시기 바래요.
< 우월한 가독성 경진대회 > 두둥~
너무 길지 않은 어떤 함수에 대해 자기 자신이 보기에 가독성 좋은 코드와 동일한 함수의 나쁜 코드의 예를 비교해 주세요. 그 좋은 가독성이 객관적일 필요는 없고요. 제가 그 가독성 우월한 코드를 제 방식대로 줄였을때도 제 노력들이 지적받아야 할 만큼 가독성이 나빠졌는지도 평가해주시고요. '짧은 코드===바보짓'이라고 생각하셨던 분들은 흔쾌히 참여하실것으로 기대할께요. 다만 제가 오랜 기간 동안 터득한 짧게 쓰는 요령들중 단 한개도 안좋아 보인다는 점에 동의하시는 것 같으니, 제가 제시한 방법은 단 한개도 쓰지 않으시길 바래요. 만약 쓰시면 바보인증.. 쿠~ ;P
시연할 함수와 언어는 본인 마음대로 정하셔도 되는데요. 사람마다 편차가 있을 것이므로 제가 간단한 것 하나 제시할께요. 제가 제시하는 함수는 "어떤 토큰문자로 구분된 어떤 문자열에서 주어진 문자열 항목을 찾아서 추가,삭제,교체를 수행하기" 이에요. 함수를 3개 만드셔도 되고 1개로 3가지 기능을 하셔도 되요. 인자설계도 마음대로 하세요.
제가 제시하는 함수는 아래와 같아요.
"A;B;C" 문자열에서, 1. "A;B;C;D" := sMod_sDMss( 'A;B;C' , '' , 'D'); // "D" 추가하기: 2. "A;C" := sMod_sDMss( 'A;B;C' , 'B' ); // "B" 삭제하기 3. "A;E;C" := sMod_sDMss( 'A;B;C' , 'B', 'E'); // "B"를 "E"로 교체하기
// [흔히 볼법한 무난한 코드 예] ==================================================================
function sMod_sDMss ( const TargetingText: string ; SearchingText: string=''; ReplacingText: string=''; const Tokken : char =';' ): string; var foundIndex : integer; TargetingStringList: TStringList; begin result:=''; if ( SearchingText = ReplacingText ) then begin exit; end; TargetingStringList := TStringList.Create; TargetingStringList.Delimiter := Tokken ; TargetingStringList.DelimitedText := TargetingText ; TargetingStringList.BeginUpdate; if ( SearchingText = '' ) then begin if ( ReplacingText <> '' ) and ( TargetingStringList.IndexOf( ReplacingText ) = -1 ) then begin TargetingStringList.Add(ReplacingText) // 'A;B;C' <=add('A;B' , '' , 'C'); end; end; else begin foundIndex := TargetingStringList.IndexOf( SearchingText ); if ( foundIndex > -1 ) then begin if ( ReplacingText = '' ) then begin TargetingStringList.Delete( foundIndex ) // 'A;C' <=del('A;B;C', 'B' '' ); end; else begin TargetingStringList.Strings[ foundIndex ] := ReplacingText; // 'A;D;C' <=ren('A;B;C', 'B', 'D'); end; end; end; TargetingStringList.EndUpdate; result := TargetingStringList.DelimitedText; TargetingStringList.Free; end; end; //======================================================================================
// [짧은 코드 예] ===========================================================================
// 부디 컬러로 구분된 화면을 상상해주세요. ;P
function sMod_sDMss(const sDM_:string;s_:string='';sNew_:string='';const c_:char=';'):string; var p:integer;sl:TStringList; begin result:='';if s_=sNew_ then exit;//---------------------------------------------------- sl:=sl_s(sDM_,c_);with sl do begin BeginUpdate; if s_=''then begin // 'A;B;C' <=add('A;B' , '' , 'C'); if (sNew_<>'')and(IndexOf(sNew_)=-1)then Add(sNew_)// 'A;C' <=del('A;B;C', 'B' '' ); end else begin p:=IndexOf(s_); // 'A;D;C' <=ren('A;B;C', 'B', 'D'); if p>-1then begin if sNew_=''then Delete(p)else Strings[p]:=sNew_ end end; EndUpdate end; result:=s_sl(sl) end; //======================================================================================
불특정다수가 보는글에 ㅂㅅ 이라는 말이 쓸데없이 너무
불특정다수가 보는글에 ㅂㅅ 이라는 말이 쓸데없이 너무 많이 들어갔네요. 솔직히 말해서 좀 읽기 거북스럽습니다.
이전의 글에서 쓰셨던 "짧은코드"라는 말도 원래 쓰셨던 그 의도와 상관없이 주관적인 의견과 일반적인 의견의 논점이
뒤섞여있죠. 그래서 님이 쓰셨던 의도와 상관없는 논점들의 글이 뒤섞여있고요.
이 글 역시 마찬가지네요. "가독성"이라는 말 자체가 일반적으로 많이 쓰이는 말이지만,
주관성도 함께 내포하고 있습니다. 게다가 예시로 보이신 것도 뭐랄까 억지스러운게 보이고...
이 글 역시 님의 의도와는 상관없는 댓글로 넘쳐난다에 한표입니다;;
"예"는 참고하시라 제시하는것이지 "주장"이 아니에요.
긴게 좋다는 분이 계셔서 최대한 길게 쓰려고 나름 노력한 예제인데요..
맘에 안드시면 직접 맘에 드는 "예"를 보여주시면 되지 않겠어요? :p
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
짧은 코드가 가독성이 나쁜 게 아니라 관심법을 써야
짧은 코드가 가독성이 나쁜 게 아니라 관심법을 써야 하는 코드가 가독성이 나쁜 것입니다.
다른 사람이 내 의도를 충분히 알 수 있게 불필요할 정도로 자세하게 나의 의도를 밝히는 코드가 좋은 코드입니다.
내 의도를 밝히는 수단은 여러가지가 될 수 있습니다. 들여쓰기, 변수 이름, 주석...
그런 관점에서 볼 때, 님이 지난번에 올린 글은 코드로 치면 최악의 코드입니다.
자신의 의도와 가정을 충분하게 서술하지 않고, 자의적으로 단어를 자신만의 뜻으로 사용하는 것도 보이는군요.
이래 가지고서는 사람들이 님 입맛대로의 답글을 올려주지 않는 것도 어쩌면 당연합니다.
님이 주장하고자 하는 내용은 잘 알겠는데
님이 지난번에 올린 글이 바로 님이 주장하고자 하는 내용을 부정하는 실제 사례가 될 것 같네요.
님은 불필요한 내용이라 생각해서 불필요한 내용 생략하고 글을 올렸는데 다른 사람들은 그걸 다르게 받아들이고
님이 원하지 않는 반응을 보이는거.
코드에서도 마찬가지 일이 일어나지 않을까요?
그리고 그럴 때마다 '수준낮은 조직은 어리석었던 역사를 알고도 반복'한다며
님의 코드를 오해한 사람들을 병신취급하면서
병신병신 랩을 하는 글을 올리실 건가요?
익명님도 저번글의 의도를 "가독성"으로 이해하시는듯 싶은데요.
제 의도는 그저 제가 모르고 있을 "짧게 쓰는 요령"만을 여쭌 것 뿐이고,
이 의도를 좀 더 분명히 묘사하기 위해 나름 성의있게 준비한 제가 사용하고 있는 "예"를 보여드린 것 뿐이고,
혹시 "가독성" 여부로 얘기가 샐까봐, 그건 고려하지 말아달라 분명히 명시해 드렸어요.
(왜 "예"를 "주장"으로 받아들이시죠? --;)
제게 짧게 쓰는 요령을 설명해 주실 분들에게 제가 짧게 쓰려는 이유를 굳이 설명할 필요는 없지 않겠어요? 제가 짧게 쓰려는 이유를 설명하고 있었다면, 그것이야말로 길게 쓰시는 분들을 향한 "주장"으로 보였지 않았을까요?
이 간단명료한 물음에도 불구하고, 제가 듣고자 하는 바(짧게 쓰는 요령)를 "가독성"으로만 바라보려는 분들이 불가피하게 그럴수 밖에 없었단 말씀이신가요? 저는 응답자마다 이해의 정도와 성품이 다양할 수 있다고 생각해요. 어떤분들은 제대로 알아들으시고, 어떤분들은 생각이 짧을 수도 있겠지요.
다들 코딩에 능통하신 분들이실텐데, 제가 "짧게 쓰는 요령"을 듣기 위해, 어떻게 했어야 했었는지 예를 보여주시면 담번에는 신경쓰도록 해볼께요.
그리고 저번 글에 관한 지적은 저번 글에 남기셨어야지 싶어요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
pseudo code와 유사한 코드가 가독성이
pseudo code와 유사한 코드가 가독성이 좋더군요.
변수 이름에 local_string 보다는 그냥 string이 나아 보입니다.
지역변수는 지역에서만 사용되니까 굳이 붙일 필요는 없다고 생각합니다.
변수 이름을 너무 줄이면 처음보는 사람은 의미 파악에 시간이 걸릴 것이고
변수 이름이 너무 길면 코드가 너무 길어지는 단점이 있습니다. 코드가 너무 길어지면 한눈에 안들어옵니다.
개인적으로 자바와 루비 함수명 toString, to_s 비교할 때 소문자,대문자 결합보다 언더바가 가독성이 더 좋다고 생각합니다.
자주 사용하는 함수명은 to_s 처럼 축약해도 바로 의미를 알 수 있으니 사용빈도가 높은 함수명은 축약된 형태가
* 타이핑이 줄어듬. 이는 타이핑 에러를 감소 시킴
* 라인의 길이가 줄어서 파악이 쉬움
위와 같은 이유로 좋은 것 같습니다.
아싸 트롤에 낚여보자
언제는 짧은 코드 원한다면서요?
IOCCC 당선작 중엔 2KB짜리 비행 시뮬레이터도 있고, 4KB가 안되는 OS도 있습니다. 더 이상 뭘 원하십니까?
http://blog.aerojockey.com/post/iocccsim
http://www.ioccc.org/2004/gavin.hint
"용량" 줄이기가 "짧은" 소스코드에 대한 수사적 표현이라니, "수사적(rhetoric)"이라는 말이 무슨 뜻인지는 아시나 궁금해지네요. 용량이 작은 코드가 짧은 코드입니다.
여기서 가독성이 좋은 코드가 어쩌네 저쩌네 해봤자 다음 글에선 "다들 이해 못하고 딴소리 하시네요, 가독성이 좋다고 표현한 것은 xxx yyy zzz에 대한 수사적(Rhetoric) 표현이에요." 하고 혼자 상상의 나래를 펴시겠죠? 이보세요, 다른 사람들이 착한아이 님 머릿속에 들어갈 수는 없단 말입니다. 사실 좀 머릿속이 궁금해지긴 하네요.
언제는 짧은 코드 원한다면서요? >> 네. 긴
언제는 짧은 코드 원한다면서요?
>> 네. 긴 코드를 원한다고 한적 없어요.
IOCCC 당선작 중엔 2KB짜리 비행 시뮬레이터도 있고, 4KB가 안되는 OS도 있습니다. 더 이상 뭘 원하십니까?
http://blog.aerojockey.com/post/iocccsim
http://www.ioccc.org/2004/gavin.hint
>> 그래서 IOCCC의 목표가 "짧은" 코드인가요? "읽기 어려운"(Obfuscated) 코드 인가요? 공교롭게도 읽기 어려운 코드가 짧은 경우는 있겠지요. 하지만 저는 짧은 코드를 일부러 읽기 어렵게 만들려하지는 않아요.
"용량" 줄이기가 "짧은" 소스코드에 대한 수사적 표현이라니, "수사적(rhetoric)"이라는 말이 무슨 뜻인지는 아시나 궁금해지네요. 용량이 작은 코드가 짧은 코드입니다.
>> 용량이 작은 코드가 결국 짧은 코드라서 "용량이 줄이기" 했어요. 제 표현이 틀렸나요?
여기서 가독성이 좋은 코드가 어쩌네 저쩌네 해봤자 다음 글에선 "다들 이해 못하고 딴소리 하시네요, 가독성이 좋다고 표현한 것은 xxx yyy zzz에 대한 수사적(Rhetoric) 표현이에요." 하고 혼자 상상의 나래를 펴시겠죠? 이보세요, 다른 사람들이 착한아이 님 머릿속에 들어갈 수는 없단 말입니다. 사실 좀 머릿속이 궁금해지긴 하네요.
>> 본문을 다시 읽어주세요. 이글은 다른분의 주장을 평가하려는게 아니라 그냥 예를 보여달라는 말이에요. 일단 가독성 좋은 코드의 예나 보여주세요. 보여주신 코드가 정말 가독성이 좋은지 나쁜지에 대해 아무 평가도 하지 않겠어요. 그냥 지금 작업중인 본인의 코드를 복사해 보여만 주세요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
이런 억지스럽고 ㅂㅅ(이글의 표현을 빌자면) 같은
이런 억지스럽고 ㅂㅅ(이글의 표현을 빌자면) 같은 글은 본인 블로그에나 써주세요. 갈수록 공해수준이네요.
제 후임이 저런 코드를 쓰면 뒤통수를 때려줄거라는건 장담하죠.
이상한 트집 따위에는 답글을 안 달테니 그리 아세요.
그럼 본인이 생각하기에 후임을 칭찬한 만한 코드의 예를 보여주세요.
그럼 본인이 생각하기에 후임을 칭찬한 만한 코드의 예를 보여주세요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
남에 글이나 함수'를 이해하기란 어렵습니다.
함수'를 사용할때는 이런거 같습니다.
함수'이름 보다도... 중요한건
1. 함수'의 용도설명
2. 함수'사용 예제소스
3. 함수가 구분되기 쉬운가. - 아래 글 보고 추가해서 적어봅니다.
어디에 어떻게 쓴다.를 알게 되면.
그 함수는 이름이 어떻든. 잘 쓰여지게 될것입니다.
사실. 가독성'은 사람마다 다르기 때문에.
어느정도 자신이 알아볼정도로만 맞추고 알리면 될거 같습니다.
결과적으로. 가독성'보다는 함수'의 내용과 용도. 예제.가 중요하다고 생각됩니다.
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
가독성이라는 단어는 이해하는 사람마다 다 다르게
가독성이라는 단어는 이해하는 사람마다 다 다르게 받아들입니다.
즉, 가독성이라고 하는 것 자체가 허구라는 거죠.
내가 아무리 이게 읽기 좋아라고 말해도, 누군가는 반대할 수 있는게 가독성입니다.
가독성은 취향에 따라서, 알고 있는 지식의 수준에 따라서 얼마든지 달라질 수 있는 문제니,
어느 누군가 대단한 예제를 보여준다고 한들, 그 조차 납득못할 사람은 수두룩 합니다.
가독성은 결국 합의나 강요에 의해서 생기는 겁니다.
가능하면 합의를 하면 좋겠지만, 일이라는게 언제나 잘 풀릴 가능성은 적으므로,
보통은 윗사람이나, 더 똑똑한 사람, 더 경험많은 사람에 의한 강요로 끝날 때가 많지요.
취향문제라면 뭐 강요라도 했을 때 무엇을 원하는지 이해는 하겠지만, 지식의 문제라면 강요해도 뭘 하라는 것인지 이해조차도 못하겠지요.
만약 강요가 안먹히는 단체거나 개인이라면, 뭐 간단합니다.
절이 중을 쫓아내거나, 중이 절을 나오면 됩니다.
그냥 제 가독성에 대한 성향을 밝히자면,
코드는 서술하는 식보다는, 짧게 적는 걸 선호합니다. <- 이걸 싫어하는 사람 많습니다.
단지, 이름은 가능한한 목적에 짧게 붙이는 것을 선호하지만, 필요하다면 충분히 길게 적습니다.
너무 이름이 길어질 수 있다면, 이름은 축약해서 붙이고 주석으로 처리하지요. <- 이것도 싫어하는 사람 꽤 되더군요.
그리고 생각날 때마다, 문제가 생길 때마다, 이름도 꽤나 자주 바꾸는 편입니다. <- 이것도 정말 정말 싫어하는 사람 많습니다.
------------------------------
How many legs does a dog have?
짧고 간결한 코드를 원하신다면
lisp을 해보세요... 별천지가 열릴 겁니다.
...And all in war with Time for love of you,
As he takes from you, I engraft you new.
-Sonnet XV
전산계획설계사 지망 영문학과생
별천지 예를 보여주세요.
여러 언어중에 짧은 언어를 고르는 문제는 아니거든요.
어쨌든 LISP의 별천지 예를 보여주세요. 이 글에서 예로 보여드린 함수를 lisp으로 만들어보여주시면 더 좋고요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
직접 해보시고 느껴보시죠. 낄낄낄.
직접 해보시고 느껴보시죠. 낄낄낄.
...And all in war with Time for love of you,
As he takes from you, I engraft you new.
-Sonnet XV
전산계획설계사 지망 영문학과생
많은분들이 오류를 범하고계시지요. 코드는 간결함이
많은분들이 오류를 범하고계시지요.
코드는 간결함이 아니라 하는 목적과 결과에 의해서 평가되어야 합니다.
아무리 간결해봐야 아무짓도 않하는 코드라면 쓰레기고 아무리 지저분한 스파게티코드라도 완벽한 목적을 달성하는 코드라면 신의코드입니다.
BSD쪽의 코드들은 대부분 unix 축약형을 선호합니다. 나이 좀 드신 분들이 코딩을하셔서 그럴수도 있지만, 어차피 서로간의 암묵적합의로 아는 단어라면 길게쓸필요가 없습니다.
길게 써봐야 컴파일러에게 어려운일만 시키는 노동일뿐이지요
당신이 짠 모구아 소스를 보고
당신이 짠 모구아 소스를 보고 싶습니다.
http://kldp.org/node/56795#comment-232925
언어 : [명사] 생각, 느낌 따위를 나타내거나
언어 : [명사] 생각, 느낌 따위를 나타내거나 전달하는 데에 쓰는 음성, 문자 따위의 수단
컴퓨터하고 의사소통만 하실꺼면 착한아이님께서 저번 예로 보여주신 코드는 좋은의 코드이구요(컴파일러가 고마워할 것 같습니다.)
사람과의 의사소통에도 사용하실 예정이라면 최악까진 아니여도 그냥 그저그렇다고 생각됩니다.
그리고 경연대회 열어주신 코드는 의미가 없습니다. 보통 인간에게 가독성이 좋은 코드란 객체 또는 함수로 얼마나 잘 분리해서
이름을 보기 좋게 지어 실제구현부를 일일이 살펴볼 필요없이 전체 프로그램의 흐름을 얼마나 더 잘 이해할 수 있도록
구현되어 있는가가 더욱 중요하지 치환함수가 어떻게 치환시키는 과정이 궁금하지는 않단 말입니다.
구현내용 자체의 가독성을 논하고 싶으신 거라면 네이밍 규칙보다는 개인의 습관에 더 치우친다고 생각하는데요.
말꼬리 잡는거 좋아하시는거 같아서 말씀드리는데 "보통 인간에게"란 말로 도망갈 구멍 만들어 놓은것도 알아보셨으면 좋겠네요.
그동안 답글 중에서 lmk378님이 제일 낫네요.
그동안 답글 중에서 lmk378님이 제일 낫네요. 의견 감사해요. :)
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
이름짓기에 따른 개인적인 의견
함수나 변수의 이름은 컴파일러에게 이건 이것과 같다라는 의미밖에 없습니다.
변수의 이름을 잘지으려고 하는 이유는 사람에게 중요한 정보를 전달하기 위해서지요
좋은 코드를 작성하기 위해서는 아래 두가지 모두 염두해두셔야 합니다.
(컴파일러에게 전달하는 정보가 아닌 사람에게) 필요한 정보를 전달하고 있는가
변수나 함수명이 너무 길지는 않는가
긴이름은 오타를 내기도 쉽고 한눈에 들어오지도 않습니다.
그렇다고 약자를 남용하는 것은 해당 약자에 대해 알지 못하는 사람이라면
이름으로 별다른 의미가 없거니와 알아도 익숙치 않다면 눈에 잘 들어오지 않습니다.
이름을 짓기 전에 어느 정보가 필요한가 부터 파악하고 (필요없는 부분은 과감히 없애고)
그 이름이 길어진다면 이에 대한 절충안으로 보통 메타포를 이용하는 방법도 있습니다.
예를 들어 변수 이름에 타입을 붙이는 버릇이 있으신 분들이 있습니다.
사실 코드가 길어 선언부분을 찾기 어렵다면 이정보는 유용하기는 합니다.
그러나 타입을 붙이기 전에 사실 함수의 길이가 짧다면 굳이 해당 정보를 넣지 않더라도
선언과 사용하는 곳이 한눈에 들어와 파악이 가능합니다.
변수의 타입이 헷깔려 타입약자를 이름에 붙이고 싶은 마음이 생긴다면 일단 해당
정보를 넣기전에 함수의 길이부터 줄이는게 더 좋은 방법일수도 있습니다.
메타포의 경우
환율를 관리하는 프로그램을 작성하고 합시다.
여러 나라의 돈을 가지고 있다가 이를 특정시점에 모두 달러로 바꿀수도 있습니다.
이럴 경우 미리 달러로 바꾸어 가지고 있다면 시점에 따라 환율이 변하므로
값이 정확하지 않으므로 각 Money를 한번에 담고 있는 객체가 필요해 집니다.
단순히 역할로 생각해 본다면 해당 클래스 이름을 MoneyContainer
로 짓는 것도 적당하다고 여겨집니다.
(그러나 개인적으로 MoneyList는 별로 맘에 들지 않는데 해당 역할뿐만아니라 내부 자료구조까지 이름에 드러내고 있기 때문입니다.)
그러나 이 대신 Wallet이라고 짓는다면 어떨까요? 이전이름과 같이 역할은 잘 드러내면서
더 짧습니다. (해당 코드는 TDD by example에서 따옴)
이러한 방식으로 이름을 짓는것을 메타포를 이용한 이름짓기라 합니다.
메타포 좋은데요?
남용하면 오히려 위험할 수 있겠지만, 좋은 아이디어네요.
전에 익명분께 여쭙고 싶은데요.
http://kldp.org/node/124302 <- 여기 두번째 답글 익명분께서 ".. 위에 열거한 것중에 좋아보이는 것은 단 한개도 없네요." 라고 하셔서 여쭙는데요.
좋아보이는게 단한개도 없다는 그 열거한 것 중 "* 연산자 사용이 최소가 되도록 수식 변형 시키기"라는 항목의 예를 한번 볼까 해요.
아래 코드는 옆자리 동료분이 서적에 나와 있는 식을 참고해 만든 함수인데요.
제가 아래와 같이 바꿨어요.
그 익명분께서는 "괜히 소스코드 줄인다고 오히려 읽기 어렵게 만드는 것은 바보같은 짓이죠."라고도 말씀하셨는데요. 연산자 사용을 최소로 줄인 방법이 "좋아보이지 않는지", 이렇게 줄인 코드가 "읽기 어렵게 만든것인지" 혹은 "바보같은 짓"인지 의견주시기 바래요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
성능상의 제약이 없다면 위의 코드 아래나 위쪽에
성능상의 제약이 없다면 위의 코드가 일단 더 읽기 좋고, 아래나 위쪽에 주석으로 구현하려는 수식을 적는게 더 좋겠지요.
아래처럼 적으면 성능은 올라갈 수 있을지 몰라도, 읽기 편하다고는 할 수 없지요.
한눈에 다 들어오는데 굳이 일일이 변수로 분리할 필요가 없지요.
더 복잡한 수식이면 또 다를 수 있지만 어쨌든 현재 코드로 보면 위쪽이 더 보기 편합니다.
------------------------------
How many legs does a dog have?
그렇군요.
위 코드를 봐서는 무슨 식으로부터 유도가 된 것인지 알 수 없기 때문에, 식의 의미를 이해할 수 없었고, 수식의 의미가 바뀔 때 어디를 고쳐야 할지 알아낼 수 없었어요.
하지만 아래 코드로 줄이고 나니 수식의 의미를 이해하기 쉬웠고, 의미가 바뀔때 간단히 변경할 수 있었어요. 성능뿐 아니라 오류 발생가능성도 줄지요.
참고로 이 동료분의 다른 함수는 이 예보다 어처구니 없이 길어요. 책에 있는대로 입력해서 동작하니까 그냥 냅둔거지, 수식의 의미를 쉽게 파악할수 있어서 길게 놔둔것 같진 않네요.
셈말님 코드는 어떻게 생겼는지 궁금한데요. 본인이 작성한 어떤 함수를 예제로 복사/붙여넣기 해서 보여주실수 있을까요?
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
저 같으면 위 코드로 작성하고 주석을 붙이거나 수식이
저 같으면 위 코드로 작성하고 주석을 붙이거나 수식이 들어있는 논문/문서를 링크를 겁니다.
아래처럼 작성하는 경우도 있는데, 성능문제 때문이지 결코 가독성 때문이 아닙니다.
프로그래밍 언어로 아무리 보기 좋게 뜯어고쳐봐야, 예쁘게 수식 나와있는 문서만 못합니다.
문서의 수식과 1:1 대응하는 모양으로 작성하면, 아무리 길고 더러운 수식이라도,
코드 위치만 봐도 수식에서 어디쯤인지 쉽게 알 수 있지요.
------------------------------
How many legs does a dog have?
제가 줄인 저 코드는 전개된 수식의 원형을 나타내요.
만약 b1의 부호를 바꾸게 되면 d1,e1,f1도 모두 자동으로 바뀌지요. 하지만 전개된 식에서는 어느항에서 부호가 바뀌어야하는지 그냥은 알수가 없어요. 코드의 길이를 줄이는 건 성능뿐 아니라 유지관리면에서 이득이 있다고 생각해요. 그나저나 셈말님의 간단한 코드 좀 보여주시면 안될까요?
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
저라면 위에 코드 그대로 적는다고 말씀드렸는데, 왜
저라면 위에 코드 그대로 적는다고 말씀드렸는데, 왜 계속 코드를 요구하는지 이해할 수 없네요.
그리고 성능이랑 유지보수는 가독성하고 관계가 없습니다.
어느새 주제가 바뀌었나요?
------------------------------
How many legs does a dog have?
가독성(읽기 좋은)은 결국 코드의 구조를 이해하기
가독성(읽기 좋은)은 결국 코드의 구조를 이해하기 위함일텐데요. 전 성능 좋고 유지보수 편한 코드가 읽기 좋은데, 성능과 유지보수가 가독성과 무관하다고 생각하시는 군요.
실제 본인코드를 말씀하시는 이유대로 하고 계시는지 궁금해요. 코드 5줄정도 보여주시는게 곤란하신가요? 곤란하시면 굳이 보여주실 필요는 없어요. 더 여쭙진 않을께요. 즐거운 코드하세요~ :)
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
가독성과 유지보수와 성능은 셋 다 전혀 별개의
가독성과 유지보수와 성능은 셋 다 전혀 별개의 문제이다.
물론 두마리, 혹은 세마리를 동시에 잡는 테크닉도 있고, 세 가지를 다 추구하는 것이 어려울 수도 있지만, 그렇다고 서로간에 상관관계가 성립하지는 않는다.
그리고 애초에 전제조건이 '성능상의 이슈'를 생각하지 않는다는 상황인만큼 아래쪽이 더 낫다고 아무리 박박 우겨봐야 답은 안나온다.
셋다 상관관계가 없음을 보여주는 코드 예를 보여주실수
셋다 상관관계가 없음을 보여주는 간단한 코드 예를 보여주실수 있을까요?(기계어,어셈블리어 제외.) 예를들면, 하나는 좋은데 다른건 나쁘다든지.
제가 보여드린 코드의 포인트는 연산자를 줄임으로써 일종의 객체관계를 볼 수 있었다는 점이에요. 아래식에서 d1 은 a1 b1의 요소를 포함하고 있더라는 말이지요. 전개된 식에서는 d1이 a1,b1 요소에 어떻게 영향받는지 전개된 식에서는 알기 어렵다는 말이었어요. 그냥 장황하게 전개된 식보다 상관관계로 표현된 것이 가독성에 도움이 될 것이라는 말이지요. 줄어든 표현은 또 다른 서브함수를 만드는데도 직관적이고요. 이런 효과도 있다는 말이고요. 좋은지 나쁜지는 개인마다 판단하겠지요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
컴파일러의 발전에 의해서 철지난 테크닉이 되어
컴파일러의 발전에 의해서 철지난 테크닉이 되어 버렸지만,
Duff's device.
제시를 해 달라 해서 제시를 해 줬더니 왜 낼름
제시를 해 달라 해서 제시를 해 줬더니 왜 낼름 받아먹고 말이 없냐 엉?
니가 하는 일이 늘 그렇지... 괜한 고집에 딴지 걸다가 털리는거.
중복되는 연산을 줄여서 효율성을 높이는걸 무식하게 '소스코드 용량을 줄이면 좋다'라고 일반화하는 놈은 너밖에 없다.
그걸 '용량'이라고 표현하는 놈도 너밖에 없고
맛과 냄새가 다른데, 같다고 생각하는 사람에게 어떻게
맛과 냄새가 다른데, 같다고 생각하는 사람에게 어떻게 이유를 대야할지 막막하군요.
지금 폭우가 내리고 있는데, 비를 보여달라는 사람에게 뭐라고 해야할지 역시 막막합니다.
그나마 부족해도 노력하는 분이라고 생각하고 있었는데, 못받아들이는게 아니고 안받아들이는 사람에게 하는 말이 무슨 의미가 있을까요.
지금껏 그래도 꾸준히 착한아이님 글에 댓글을 붙이면서 나름 노력했다고 생각하는데, 이제는 지쳐서 포기하겠습니다.
------------------------------
How many legs does a dog have?
저는 예제로 든 두가지 형태의 소스를 모두 쓰는데요
저는 예제로 든 두가지 형태의 소스를 모두 쓰는데요 (그때그때, 기분따라)
저렇게 꼬여 있는 수식이라면 남들이 썼으면 어떤식으로 썼든지 읽기 힘들고, 내가 썼으면 어떻게 써도 읽기 쉽네요.
예를 들어, cosine = sin(phi), sine = cos(phi) 라는 식으로 변태스럽게 배정하지 않는 한 더 어려워지지는 않는 것 같아요.
피할 수 있을때 즐겨라! http://melotopia.net/b
일단 저번글에 대하여 한마디 하고 싶네요.
논제를 벗어난 댓글이 많다고 하셨는데 그건 그냥 논제를 제시하지 않으선 글쓴분의 잘못같습니다. 누구라도 그 글을 보면 일부러 가독성을 포기하고 용량을 줄이려 하는구나라는 생각이 들지 가독성을 위해서 용량을 줄인다는 생각은 못합니다. 그러니까 IOCC같은 얘기를 하는것이고요.
결과는 마찬가지일것 같아요.
만약 제가 가독성을 높이기 위해 용량을 줄이겠다고 말했다면, 사람들은 용량을 줄이는 방법을 고민하기 보다는, 결국 용량을 줄이는게 가독성에 도움이 되지 않는다는 점만 지적했 을것 같네요.
저는 가독성이 개인 편차가 크기 때문에, 무엇이 가독성에 도움이 될지를 논하는 것은 용량을 줄이는 방법을 고민하는데 방해가 될 것이라 생각했어요.
사람마다 이해하는 수준은 다를수 있어요. 몇 안되지만 제 논제를 이해하신 분도 계시고요. 저는 당부한 부분 정도는 알아듣고 고민해 볼 수 있는 분들일 줄 알았어요. 가독성을 고려하지 말아달라고 당부했는데도 불구하고, "가독성을 포기하고 용량을 줄이려는 구나"라고 짐작하는 것은 그분들의 부정적인 면만 들춰내고 보는, 건성(성의없음)이었을 수도 있지 않았을까요?
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
니가 맨 처음에 논제를 올릴 때
가독성 외에도 생각하지 말아야 할 조건 하나를 더 걸었는게 그건 실행 속도 성능이지.
실행 속도 성능을 고려하지 않는다면 니가 위에 10월 6일에 올린 두가지 코드는 그게 그거다 잉?
아니 오히려 그냥 위처럼 풀어 쓰는게 차라리 그냥 읽는 데 훨씬 낫다. 위아래로 왔다갔다 하면서 읽을 필요 없으니까.
위에서 아래로 바꿔야 될 이유는 소스 코드 용량 측면에서 접근해야 될 것이 아니라.
* 중복되는 부분의 제거
* 같은 결과값을 반환하는 함수 호출의 최소화
* 식의 변형을 통한 연산 회수 줄이기
라는 측면에서 접근해야 하는 거고 이 세가지는 모두 실행 속도 측면하고 연관된다.
니가 맨 처음에 논제를 올릴 때 '무엇을 위해서' 소스 코드 용량을 어떻게 줄일까요 라고 올렸으면 아주 간단하다.
근데 니 태도는 어땠지?
가독성하고 실행 속도 생각하지 말고 걍 줄이라고 그랬지?
근데 뭐에 쓸건지는 얘기도 안했지?
그래서 뭐에 쓸거냐고 하니까 '답변할 놈들이 답변하면 알아서 취사 선택할 건데 굳이 밝힐 필요는 없다' 그랬지?
그래놓고 사람들이 뭐라 하니까 삐져 가지고는 이게 대체 몇달째 이렇게 행패부리고 있는거냐?
결국 니 목적은 이거 아니냐.
> 그분들의 부정적인 면만 들춰내고 보는, 건성(성의없음)이었을 수도 있지 않았을까요?
'나한테 뭐라 하는놈들 다 병신임'
이거 주장하려고 대체 몇달째 이렇게 난리를 치고 있는거니.
이제 쪼잔한 일 가지고 그만 행패 부리고
가서 니가 만든다는 무슨 프로그래밍용 에디턴지 뭔지나 진도를 좀 나가봐라.
니가 처음에 만든다고 떠든 것의 절반이라도 구현을 한다면
넌 굳이 니가 잘났고 다른 놈이 병신이었음을 이렇게 몇달째 횡설수설 떠들지 않아도 된다 잉?
익명분들을 대상으로 논의를 할때는
이해의 수준이 다양한 익명분들을 대상으로 논의를 할때는 논의의 진행을 방해하는 요인이 많이 생기지요..
"무엇을 위해서"라고 시작했다면, 용량줄이는방법을 고민하기보다는, 용량줄이기가 무의미하다는 의견만 나왔겠지요. 저는 그런 불필요한 의견을 방지하기 위해 단서를 붙인 것이고요. 무슨 목적이든 용량줄이기가 항상 해로운 작업이라면, 그냥 무시하고 냅두면 되는 일이었지 않겠어요? 제가 무슨 이유로 용량줄이기를 시도하는지 모르는 상태에서 섯불리 "바보짓" 혹은
"엉터리" 논제로 판단하는 것은 성의가 있어 보지는 않았어요. 저는 이해 못하는 수준을 지적하는것이 아니라, 성의없는 수준을 지적하는 것이에요.
ps. 제가 만든 에디터는 목표한 만큼은 작년에 구현은 했어요. 상업용까지 가려면 아직 갈 길이 멀긴하지만, 특허문제를 해결해야해서 부패시키고 있는 중이네요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
참 삐딱한 놈일세
> 저는 이해 못하는 수준을 지적하는것이 아니라
아 그래서
> 이해의 수준이 다양한 익명분들을 대상으로
이런 식으로 은근 슬쩍 이해의 수준의 낮다고 까대셨어여? 참 잘하셨네요.
> 무슨 목적이든 용량줄이기가 항상 해로운 작업이라면, 그냥 무시하고 냅두면 되는 일이었지 않겠어요?
아~ 그러세요? 그러는 너는 "논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P" 라면서
다른 사람들이 가독성도 목적이 아니고 속도 향상이나 효율성도 고려하지 않고 막무가내로 소스 코드 줄이는거에 대해 비판적으로 나오니까
그렇게 발끈해서 몇달 째 이런 식으로 비비 꼬인 글을 줄창 올려대고 계신 건가요?
댁이나 좀 '수준 낮은 익명들'을 무시하고 '생각 짧지 않은' 논의를 좀 이어나가 보지 그러셨어요?
니가 올린 논의의 진행을 가장 크게 방해하는 요소는 오히려
1. 목적을 밝히는게 오히려 논제 진행에 방해가 될 거라는 도무지 알 수 없는 논리의 피해의식
2. 비판적인 리플이 몇개 달리면 상처입고 꼬인 행동을 보이는 유리보다 연약한 너의 멘탈
3. 자신의 불쾌한 심정을 불특정 다수에 대한 경멸과 증오로 전환하는 비뚤어진 자존심
4. 몇달이 지나도 자신이 공격받은 것을 잊지 못하는 집착
이거다.
니가 정말로 발전적인 논의 하고 싶으면
제대로 자세하게 밝혀 오해의 여지를 줄이고 제대로 논의의 장을 만들던가.
하지만 넌 안그러잖아?
오히려 무슨 '가독성 경진대회 :P 베~' 이딴 글이나 올리면서 도발이나 해대고.
솔직히 말해봐라. 그딴 글 올린 의도가 생산적인 논의를 하고싶어서였니
아니면 어떻게든 니 상대들을 병신으로 만들고 싶어서였니?
수준이 "다르다"는 생각을 왜 수준이 "낮다"고
수준이 "다르다"는 생각을 왜 수준이 "낮다"고 받아들이죠? 어떤 영어를 못 알아듣는다면, 그것은 영어에 대한 훈련이 덜된 것이지 판단수준이 상대적으로 "낮다"는걸 의미하는 것은 아니지 않겠어요? 부정적인 면을 지적하려는 분들의 심성은 받아들이는 것에도 긍적이진 않을듯 한데, 아무도 수준이 "다름"을 지적하지 않는다면, 그분들은 현재 자신들의 판단수준이 중립적인지 합리적인지 돌아볼 기회를 갖지 못 할수도 있어요. "까대는 것"으로 느끼셨다면, 안타깝지만 저를 포함해 우리 모두 그닥 수준이 "높지" 않다는걸 알고 있었으면 해요.
저는 어떤 목적이 긍정적인지 부정적인지는 논의하고 싶지 않고요. 제가 생각지 못한 다른 방법에 대한 의견을 듣고 싶을 뿐이에요. 상대방 "병신" 만들어 제가 얻는게 모가 있겠어요. 코드를 길게 쓰는 방법에 대해 논의하자고 했다면 "오~ 현명한 방법"이라면서 긍정적으로 의견들을 나왔을까요? 모두가 긍정적일 긍정적인 목적을 논의하는 것이 오히려 무의미 하지 않겠어요. 긍정적인지 부정적인지는 각자 알아서 판단하시고, 방법에 대한 생각을 나누는게 더 발전적일것라 생각했어요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
아 그래서 "생각짧은" 참여자들을 위해서 가독성
아 그래서
"생각짧은" 참여자들을 위해서
가독성 경진대회 메롱~을 여셨군요!
대단한 궤변이십니다.
니가 그때 올렸던 글 다시 링크해 드릴까요?
남의 부정적인 것만 보는 성의없음을 탓하기
남의 부정적인 것만 보는 성의없음을 탓하기 전에
논제는 엉터리로 걸어놓고 니 입맛에 딱 맞는 답변을 바라는 너의 성의없음과
니 성의없는 논제에도 나름대로 답변을 해보려는 사람들을 논지의 취지조차 이해못한 사람으로 깔아뭉개는 건방진 태도를
탓하는 것이 먼저인 것 같구나.
짧은 코드에 대한 논의가 "엉터리" 였나요?
코드 길이를 줄이는 것은 성능면, 유지관리면, 가독성면에서 이득이 있을수 있다고 생각해요. 하지만 이런 이득은 개인편차가 크기 때문에 어떤 형태든 가독성이 유리한지 아닌지를 논하는 건 큰 의미가 없다고 생각했어요. 예를들면 자기가 쓴 코드는 길게 쓰든 짧게 쓰든 알아보는데 별 문제가 없는 것 처럼요.
짧은 코드가 항상 불리하기만 한게 아니라면 가치없는 엉터리 논제는 아니었다고 생각해요. 다만 공개된 게시판에서 이득적인 면은 고려하지 않고, 애써 불이익한 면만 지적하려는 분들을 자연스럽게 차단시키는건 쉽지 않네요.
짧은 코드가 가독성에 그리도 해롭다면, 가독성에 대한 논제를 새로 열면 되는데, 굳이 짧은 코드에 대한 논의를 "엉터리"로 보이게 만드는 것은 성의가 있어 보이진 않아요. 제가 그 성의없고, 삐딱하게 부정적으로 몰아세우는 분들을 지지하는건 아니니까 건방져보일수도 있겠네요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
제대로 전제조건이 설정되지 않은 논의는 엉터리다
"운하를 파는 것의 장점에 대해 논의해 보도록 해요:P"는 엉터리 논의다.
최소한 "파나마에" 혹은 "한반도에"가 붙어야 제대로 뭔가 논의가 이루어지지.
> 예를들면 자기가 쓴 코드는 길게 쓰든 짧게 쓰든 알아보는데 별 문제가 없는 것 처럼요.
전혀 아니거든? 몇달 후에 다시 보면 니가 쓴건지 아닌지도 기억 안난다. 코드 처음 짜보세요? 아마추어같이 왜이러시는지.
> 짧은 코드가 항상 불리하기만 한게 아니라면
참 사람들 말 삐딱하게 해석하네...
"한반도 대운하가 항상 불리하기만 한 게 아니라면" 운하를 파는게 긍정적이세요?
무슨 실행 속도 향상이나 효율성이 목적인 것도 아니고
아무 의도도 없는 상태로 밑도 끝도 없이 무작정 소스 코드 "용량(?)"을 줄이면
'대체로' 부정적인게 당연하지.
아 물론 아닌 사례 찾으라고 들면 백가지 천가지도 더 찾을 수 있겠지.
마치 한반도 대운하가 긍정적인 사례를 꼽자면 백가지 천가지도 더 나오듯이.
말씀하신 예가 조금 부적절해보이는데요.
말씀하신 예는
"짧은 코드의 장점에 대해 논의해 보도록 해요. = 운하를 파는 것의 장점에 대해 논의해 보도록 해요." 인것 같고요.
제가 논의하려했던 것은
"짧은 코드의 방법에 대해 논의해 보도록 해요. = 운하를 파는 것의 방법에 대해 논의해 보도록 해요." 으로 생각하셔야 할것 같아요.
>"전혀 아니거든? 몇달 후에 다시 보면 니가 쓴건지 아닌지도 기억 안난다. 코드 처음 짜보세요? 아마추어같이 왜이러시는지."
오래된 함수의 이름이나 사용법은 잊을수도 있지만, 코드를 다시 이해할 때는 길이랑 별 차이 없어요. 짧아진 규칙을 잊지는 않거든요.
"운하를 파는게 긍정적이세요?"가 아니라 "운하파는 방법이" 궁금한 것이지요. "운하파는게" 부정적이면 운하파는 방법은 논의할 가치가 없다는 말씀인가요? 긍정적 목적일때 그에 대한 방법 논의를 긍정적으로 하게되는 건가요?
어떤 목적이 긍정적인지 부정적인지 모를때, 그에 대한 방법에 대한 논의가 부정적으로 간주되는게 당연하다는 말씀인가요? 저는 목적의 극성에 무관하게 방법 정도는 중립적으로 논의해 볼수 있는 수준일거라 생각했어요.
ps. 참고로 저는 한국형 운하에 부정적이긴해요. 물론 운하파는 대한 "방법"에는 관심없고요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
방법이나 목적이나
운하를 파는 방법이 궁금해도 어디에 팔건지를 제시 안하면 밑도 끝도 없는건 마찬가지.
A: 운하를 파는 방법을 논의하죠. 운하를 왜 파는지에 대해서는 말하지 않겠어요.
B: 삽하고 포크레인하고 중장비를 동원해서...
A: 문경새재 넘을건데 병신아?
B: 엉?
그나저나 메타포를 아무리 물고 늘어 져봤자 원래의 주제가 병맛인건 변하지 않음.
말씀하신 예를 조금 보완하면요.
고속전철개발시 부정적인 의견에는 "고작 40분 단축하려고 수십억 들여 기술을 개발하나?"라는게 있었지요. 한국에서는 큰 이득이 없을수도 있지만, 그 기술을 다른나라에 팔 수 있다면 해볼만한 연구이지 않겠어요? 한국에는 운하가 불필요하지만, 운하를 파는 방법을 알고 있다면 마찬가지로 이득일수도 있지 않겠어요?
대상이 정해져야만 방법을 생각하기 시작한다면 이미 늦었을 것 같아요. 대상이 정해져 있지 않더라도 미리 방법들을 생각해 볼수 있는 자세는 되어 있어야하지 않겠어요?
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
그런식으로
메타포만 계~속 물고 늘어져라.
다른 사람들이 눈뜬 장님이냐? 니 의도를 모르게.
> 어떤 목적이 긍정적인지 부정적인지 모를때, 그에
> 어떤 목적이 긍정적인지 부정적인지 모를때, 그에 대한 방법에 대한 논의가 부정적으로 간주되는게 당연하다는 말씀인가요? 저는 목적의 극성에 무관하게 방법 정도는 중립적으로 논의해 볼수 있는 수준일거라 생각했어요.
의도를 제대로 밝히지 않는다면,
사람들은 비어있는 행간을 읽을 때 일반상식으로 부족한 부분을 채워넣는게 보통이고
그래서 사람들은 오해의 여지가 있을 때 그것을 줄이기 위해 서로 대화를 한다.
너처럼, 가독성 경진대회 :P 메롱~ 을 여는게 아니고.
논의할 범위를 한정하지 않으면 논의가 산으로 가는게 당연하지.
너처럼 범위를 거의 한정하지 않고
거기다가 오해하기 쉬운 조건까지 덧붙여 놓고서(예 - 성능은 생각하지 말기로 해요...)
니 입맛에 안맞으면 생각짧은 참여니 뭐니 하면서
너희 병신들의 생각이나 말해봐라 가독성 경진대회 두둥~을 열면
이건 뭐...
애초에 뭐하고 싶어서 논의를 내걸었니?
니가 내건 제멋대로의 리트머스 시험지로 KLDP 사람들의 수준을 검사하고 싶어서?
KLDP가 생각짧은 사람들만 우글대는 걸 증명하고 싶어서?
다른 사람이 니 목적같은건 알 필요도 없다면
니 입맛에 맞는 의견만 던져줄 필요도 없지.
익명분들을 제외하고 KLDP 분들 창의력 수준이
익명분들을 제외하고 KLDP 분들 창의력 수준이 궁금해서, http://kldp.org/node/125060 에 여쭤본 적은 있지요.
논의를 원만히 임하시는 괜찮은 분들이 분명히 있긴해요. 하지만 익명을 포함한 비율로 봐서는 좀 적은 듯 싶네요. 논의에 부적격한 익명분들이 더 많지 싶어요.
다른 글타래들은 방법에 대한 의견을 듣기 위해서고, 이 글타래는 다른분들의 예제 코드를 살펴보고자 열어봤어요.
제가 논지를 올릴 때는 논지에 관련된 의견을 듣고자 함이지, 논지의 여부를 논쟁하기 위함이 아니예요.
논지의 취지를 이해하지 못한 의견에는 가급적 답글 달지 않겠어요. :P
창의력 수준이 궁금해사??? KLDP 분들을 평가하고
창의력 수준이 궁금해사???
KLDP 분들을 평가하고 시험하는 듯한 글이 아니었구요? ㅎㅎ
이 댓글 하나에서도 부적격이라는 식의 평가가 난무합니다만..