1.  printf("Normal[%#x] : %s\n", NormalPtr, NormalPtr );

Normal[0x424678] : RAYN

이 글은 스프링노트에서 작성되었습니다.

When?

 정적 변수로써 함수에 관계없이 항상 메모리에 남아 있을때 사용

정적 함수

현재 함수가 정의 된 파일 안에서만 사용할 수 있고 다른 파일에서는 절대 사용할 수 없다.

정적 변수

다른 파일에 저장된 정적 변수를 사용하기 위해서는 Set Get을 이용해서 함수로 접근을

하여야 한다. 객체지향에서 private와 비슷한 속성.

이 글은 스프링노트에서 작성되었습니다.

 전역변수를 많이 사용하다보면 찾기 힘든 에러가 많이 생기게 되고 그로인해 많은 시간을 소비하게 된다

그렇기 떄문에 전역변수는 지양하는 것이 좋다.

매개변수의 사용

전역변수 대신에 함수에 매개 변수를 사용하도록 한다.

구조체의 사용

꼭 전역 변수를 사용해야 한다면 구조체로 사용해서

실수로 인해 전역변수의 값을 사용하거나 변경하기는 힘들 도록 한다.

이 글은 스프링노트에서 작성되었습니다.

 Point

많은 개발자 들이 주석을 경시하는 경우가 많이 있습니다. 하지만 주석은 소스코드 못지 않게 굉장히 중요한 역할을 합니다.

Content

프로그램을 개발 할 당시에는 자신의 소스코드를 주석이 하나 없어도 다 이해하고 있습니다.

하지만 몇 달이 지나고 몇 년이 지나서 다시 보게 된다면 지금과 같이 이해가 될까요?? 물론 불가능 합니다.

자신 뿐만 아니라 다른 사람이 볼 경우도 생기게 되는데 이때는 더욱 더 막막해 집니다.

그래서 주석 이라는 것은 꼭 작성을 해 주어야 합니다.

주위 몇몇 분은 전혀 주석을 달지 않는 분이 있는가 하면, 한편의 소설처럼 소스 코드 보다 주석이 더 긴 경우도

바왔습니다. 무엇이든 너무 적거나 지나치면 안한것만 못한 경우가 다반사 입니다.

주석을 자세히 달았는데 왜 좋지 않냐구요?? 만약 주석을 그 함수에 대해 일일히 한줄 한줄 다 설명해서 작성했다고

합시다. 만약 소스를 유지 보수 하게 될 경우, 수정한 소스코드에 해당하는 주석부분을 찾아서 일일히 다 수정해주어야 합니다.

이와 같이 오히려 소스 수정하는 시간보다 주석을 수정하는 시간이 더 들어 시간을 낭비하는 경우가 생길수 있기 때문입니다.

이제 주석 사용에 대한 예를 보시겠습니다.

1. 함수
2.       /*=====================================
3.         InsertNode
4. Function  : InsertNode                       <- 함수 이름
5. Prototype : void InsertNode( char *)    <- 함수의 프로토타입
6. Author     :  ChanSub Shin                 <- 작성자
7. Revision  : 1.0   2007.08.10 NEW          <- 최초 작성 날짜
8. Modified  : 2007. 08, 18 By ChanSub    <- 마지막 수정 날짜와 수정자
9. =====================================*/
10. void Node::InsertNode( char *node )
11. {
12. .....
13. }

2. 일반 소스

1.  if( *sBuf++ != *dBuf++ )        /* modified date : 2007.08.17 */
2. return 0;                        /* Not Equal */

첫 번째 방법은 함수위에 주석을 표시해서 첫 작성 날짜, 최종 수정 날짜, 작성자를 나타내며

두 번재 방법은 소스 옆에 그 코드에 대한 간단한 설명이나 수정한 날짜를 표시하는 것입니다.

이와 같이 사용하여 주석을 간결하고 그리고 깔끔하게 정리하고, 소스코드 도 마찬가지로

변수를 선언할때 코드를 TAB키를 사용하여 수직으로 줄을 맞춰서 선언 및 초기화를 해주는 것이 좋습니다.

그리고 for문이나 if문 등등에 for(int i=0;i<num;i++) 이런식으로 붙여 쓰는 경우가 많이 있는데 굉장히 읽기에

어렵습니다. for( int i = 0 ; i < num ; i++ ) 이와 같이 스페이스 바를 이용하여 적절히 띄워주어

같은 코드라도 좀더 이해하기 쉽도록 하는 것이 중요합니다.

헝가리언 표기법

프로그램의 시작시

1. /*+---------------------------------------------
2. **     Project Name       : ????
3. **     
4. **     File Name          : test.c
5. **     Revision           : 0.1
6. **     Date               : 2007.08.24
7. **     Author             : ChanSub Shin
8. **     Copyright (c) 2002 - 2003 ??? Co., Ltd
9. **     All Rights Reserved
10. +----------------------------------------------+*/

이 글은 스프링노트에서 작성되었습니다.

 Point

공동으로 프로젝트를 진행하다 보면 여러 소스 파일에서 헤더파일을 인클루드 시켜

링크에러가 많이 발생하며 초보들은 원인은 못 찾는 경우가 많이 있습니다.

1. #ifndef ~ #ifdef ~ #endif

2. #pragma once

 이 두 방법 중 하나를 선택하여 사용해서 여y러 파일이 중복 포함 되는 것을 막을 수 있습니다.

Content

처음으로 프로그래밍을 하게 되면 한 파일에 모든 소스코드를 작성하는 경우가 많습니다.

그리고 실행을 하기 위해 많은 문법 에러를 만나게 됩니다.

1. #include <stdio.h>
2. #include "data.h"
3.  extern int Add( int, int );
4. void main()
5. {
6. ....
7. c = Add( a,b );
8. printf("%d", c);
9. printf("%d", diff);
10. ....
11. }

 lib.c

1. #include "data.h"
2. int Add( int, int );
3. int Add( int x, int y )
4. {
5. diff = x - y;
6. return x + y;
7. }

data.h

1.  int diff;

 이 소스에서 lib.c와 test.c 에서 data.h 를 둘다 include 하면서 두개의 소스파일에서 모두 diff를 전역변수로

선언함으로써 C컴파일러에서 링크에러를 발생 시킵니다.

이와 같이 여러 사람과 같이 프로젝트를 진행하게 되면 수십 또는 수백개의 파일을 각자 작성하여 통합하여

실행하면서 헤더파일을 여러번 인클루드 하여 링크 에러를 많이 발생 시킵니다.

문법 에러와는 다르게 링크 에러의 경우에는 원인을 찾기가 힘들어 이를 수정하기가 까다롭습니다.

1. #ifndef _DATA_H // data가 정의 되어 있지 않으면
2. #define _DATA_H // data를 정의하라
3. int diff;
4. #endif                 // 전처리기의 끝

1. #pragma once
2. int diff

둘중에 한가지 방식을 사용하여 한번만 인클루드 해주게 하는 것을 습관 들이는 것이 좋습니다.

#pragma once가 간단해 보이긴 하지만 지원하지 않는 컴파일러도 있기 때문에

#ifndef ~ #define ~ #endif 를 사용하는 것이 좋습니다.

이 글은 스프링노트에서 작성되었습니다.

Point

프로그램은 결과도 중요하지만 과정도 중요하다.

프로그램에 있어 중요한 것은 결과가 나오느냐 하는 것이라 생각 하는 프로그래머 들이 많이 있습니다.

물론 결과를 산출하는 것이 프로그램의 목적 이기 때문에 중요하지만, 프로그램이 결과를 산출하는데

굉장히 오랜 시간이 걸린다거나, 중간에 프로그램이 죽는다거나, 많은 메모리를 차지하게 된다면

결코 좋은 프로그램을 만들었다고 할수 없습니다. 따라서 프로그램의 결과도 중요하지만 아래와 같은 중간과정도 중요합니다.

1.  코드의 최적화
   메모리, CPU의 시간과 같은 리소스를 낭비하지 않고 적잘하게 사용하는 최적화
2. 코드의 재사용성

   같은 코드를 여러 번 반복하여 작성하거나, 다른 사람이 자신의 코드를 사용할 때 별 다른

   수정없이 사용할 수 있도록 구성하는 모듈화

3. 코드의 가독성
    다른 사람이 소스 코드를 쉽게 이해할 수 있게 하는 가독성

Content

if 문은 변수의 값을 비교하여 프로그램의 흐름을 결정하는 제어문의 한 종류입니다.

하지만 if, else if 를 너무 남발함으로써 소스 코드의 가독성이 떨어질 뿐만 아니라

프로그램을 유지-보수 할때 무척 지저분해 진다는 단점이 있습니다.

프로그램의 결과도 중요하지만 오랜 시간이 지나서 자신이 다시 보거나 다른 사람들이

코드를 봤을 때 이해하기 쉽게 만드는 것 또한 중요합니다.

 예를 들어

1.  if( val == 1 )
2. ...
3. if( val == 2 )
4. ...
5.  if( val == 3 )
6. ...
7.  if( val > 4 )
8.       ...

이와 같이 코드를 작성 했을 경우 val 이 1 이 었을 때 위의 프로그램은 나머지 if에 대한 검사도 합니다.

만약 if문이 500개, 1000개가 된다면 전체 프로그램의 속도를 떨어뜨리는 원인으로 작용 하게 됩니다.

1. switch( val )
2. {
3. case STEP_FIRST:
4. .....
5. break;
6. case STEP_SECOND:
7. .....
8. break;
9. case STEP_THIRD:
10. .....
11. break;
12. }

위의 코드처럼 사용하게 되면 보기에도 좋을 뿐만 아니라 소스를 수정하기에도 편하고,

좀 더 경제적으로 프로그래밍을 할 수 있습니다.

물론 if, else if 를 사용해야 할 경우에는 어쩔수 없이 사용을 해야겠지만 이 코드와 같이

단순히 값이 같은지 비교하는 경우에는 switch~ case 문을 사용하여 좀 더 이해가 쉽도록 하는 것이 좋습니다.

이 글은 스프링노트에서 작성되었습니다.