고치고 싶은 코딩 습관

>3. 모듈화... 시키기
> 한번은 짜놓고 보니 몽땅 main(){} 안에 박혀 있더군요. 근 2천라인 되는
> 놈이 지금 그것땜에 후배 놈이 고치느라 죽을 고생을 하면서 뒤에서 째려
>보는군요. 어쩌겄냐... 함수명도 a() 이런 것을.. 니 팔자다...

함수 하나에 몰아 넣는 것이 함수 100개로 나누어 놓는 것 보다는... 차라리 낫습니다. 제가 보기에는 오히려 잘 하신것 같은데요.
제가 대규모 프로젝트를 하면서 느낀바 중 하나는
<한번만 쓰는 함수라면 그냥 함수안에 바로 집어 넣는게 낫다는 겁니다>

많은 도움이 되었습니다.
좋은 곳에 링크 걸어 주셔서 감사합니다.

님아 요즘 전문대 학생도요.

간단한 들여쓰기는 주석달기 전도는 다해요.

어느정도는요

왜 로그인이 안되징... 에라, 나는 겁쟁이다. -.-

저는 어떤 최소 단위안의 temporary변수들(클래스는 제외)은 별의미없는 이름들(a1,a2,...)을 일부러 씁니다. 주로 짜는 프로그램들의 특성상 한 단위(scope)가 300줄을 잘 넘어가지 않기 때문이기도 하지만, 오히려 이런식으로 짜면 프로그램상 중요한 변수들과 확연히 구분이 되어 편할때도 많습니다. 한때 temporary변수들도 각각 의미있는 이름을 주고 그앞이나 뒤에 temporary임을 표시하는 방법을 쓴적도 있지만(예: tTargetStringLength), 작은 scope안에서만 쓰이는 변수를 위해 머리쓰는것도 그렇고, 가독성도 오히려 떨어진다고 생각이 되어서요.

C는 온갖 종류의 pointer&memory문제가 항상 초보의 발목을 잡더군요. 대표적인것이 이쪽 모듈(함수?)내에서 malloc으로 잡은후에 같은 레벨의 모듈(함수)내에서 free해주지 않고, 다른 곳에서 해야하는 경우. 처음엔 머리속으로 이건 여기서 malloc했고 저기서 free하고.. 이걸 기억하지만, 프로그램이 커지면서 점점더 힘들어지고 깜빡 까먹기가 쉽더라구요. C인 경우에는 변수이름에 이러한 scope단위를 명시하는것도 좋은거 같습니다(pointer).

요즈음 C++을 주로 쓰게 되어 이런 문제에서 많이 해방되었지만, 옛날 C적의 포인터가지고 놀던(==헤매던) 재미가 삼삼한듯...

Zed

전적으로 찬성합니다..

커피, 과자, 하다못해 껌이라도 입에 물고 있어야하죠..ㅅ.ㅅ

예전엔 음악을 들으면서 했는데 확실히 효율이 떨어져서 음악을 껐더니..

요즘은 먹는 거라는 새로운 습관이 들어버렸네요..

먹는 거에 단점은 계속 먹다보면 언젠가는 졸리게 되죠..ㅎㅎ

그럼 잠깬다고 퀘이크류의 게임한판하고 나면..

괜히 스트레스만 더 받아가지고 산만해지기만 하죠..

MC^2 라도 구입해야할 듯..

break를 case 열에 맞추면 좋음.

switch (SomeCondition)
{
case 0 :
// dfsgsdfg
// dfdfasdfdf
break;
case 1 :
// dfsgsdfg
// dfdfasdfdf
break;
}

그리고 마약 case를 공유할 일이 있으면
switch (SomeCondition)
{
case 0 : case 1 : case 2 : case 3 :
// dfsgsdfg
// dfdfasdfdf
break;
case 9 :
// dfsgsdfg
// dfdfasdfdf
break;
}
이렇게 한줄에 쓰는게 좋음.

그런데 비구조적으로 Overlap되는 경우는 switch 문으로 분리하거나 if를 사용하는 것이 좋겠다는 생각. 예를들어 아래 경우는

switch (SomeCondition)
{
case 0 : case 1:
// dfsgsdfg
// dfdfasdfdf
case 2 : case 3 :
// ghjsdfg
// hjksdfdf
break;
case 9 :
// dfsgsdfg
// dfdfasdfdf
break;
}
이것은 이렇게 바꾸는게 좋음.
물론 불 필요한 if 문을 하나 더 사용하니 비효울적이다라는 어처구니 없는 생각을 할 사람도 있지만 이 if 문이 전체 성능에 미치는 영향은 극히 미미함.

switch (SomeCondition)
{
case 0 : case 1: case 2 : case 3 :
if (Condition(0 or 1))
{
// dfsgsdfg
// dfdfasdfdf
}
// ghjsdfg
// hjksdfdf
break;
case 9 :
// dfsgsdfg
// dfdfasdfdf
break;
}

그것이야 말로 가장 중요한 문제입니다.

첨엔 고민고민하면서 잘 짜려고 하다가

프로그램 사이즈가 늘어나고

점점 두뇌기억용량을 벗어나기 시작할때면...

그냥 때려넣게 됩니다.

하지만 그냥 때려넣는 것도 좋은 거라고 생각합니다.

ㅎㅎㅎㅎㅎ

전적으로 동감해요~~~

헝가리안 표기법은 단순히 변수의 타입만을 알리는 것이 목적이 아니라, 그 변수가 어떤 '용도'로 쓰이는지를 알려주기 위한 것이 진짜 목적입니다.

헝가리안 표기법이 유용한 경우는
타입체킹보다는..
열거체 상수에 특히 유용합니다.
오리지널 C가 쓰이는 분야는 많습니다.
임베디드시스템분야는 거의 모두 그렇지요..

저두
if() {
}
이런문장은 보기가 힘들더군요 ㅡ.ㅡa
단,
if() {
{
}
이거보단 한 라인이 줄어든다는 장점은 있지만....

잘만 쓰면 오히려 나쁘지 않은거 같습니다.

필요할때만 선언해 주면 소스코드 눈으로 볼때 시야가 좁아져서 편하더군요.

옛날에 파스칼할때는 위에 다 선언해놓구 헷갈려서

결론은 신경만 써주면 변수가 선언될 때가 변수가 사용될 때라서 코드를 알아보기 쉬워지겠지요.

저도 무작정짜는 스타일인데요.. 우선 설계부터 해놓고 짜면 쉽게
짤수 있다는걸 알면서도 그렇게 안되네요.. 버릇인지라
저도 이거 고치고 싶네요. Anonymous wrote...