ANMIAN

#include <stdio.h>

unsigned long factorialUsingRecursion(unsigned long n);
unsigned long factorialUsingLoof(unsigned long n);

int main(void)
{
        printf("10! = %lu\n", actorialUsingRecursion(10));
        printf("10! = %lu\n", factorialUsingLoof(10));
        return 0;
}

// 재귀호출을 이용한 factorial계산
// 종료조건(if)을 가장 먼저 적어주는 것에 유의
// 재귀호출은 어떻게 돌아가는지가 중요한 것이 아니라
// 어떤 수식을 그대로 옮겼느냐만 생각하면 된다.
unsigned long factorialUsingRecursion(unsigned long n)
{
        if(n <= 1) return 1;
        return(n*factorial(n-1));
}

unsigned long factorialUsingLoof(unsigned long n)
{
        unsigned long result, i;

        result = 1;
        for(i=2; i<=n; i++)
        {
                result = result * i;
        }
        return result;
}

변수 :
- 명사로 이름 짓는다. ( 변수는 data 자체를 가리키는 경우가 많다.)

- 명사로 사용할 수 없을 땐 명사화된 동사를 사용(ex: count)

- 변수이름의 첫글자는 영문 소문자로 시작

※ 헝가리언 노테이션 : type에 관한 정보를 이름에 포함시키는 방식으로 멤버변수의 경우 m_으로 시작하고, 포인터의 경우 이름 뒤에 _ptr... 뭐 이런 식의 작명법을 말한다. 이 책에서는 그러한 방법을 따르지 말라고 경고하고 있다. Win32와 MFC의 라이브러리에서 헝가리언 노테이션을 따르는 것이 대중적인 사용의 주된 이유지만 type에 관한 정보는 선언할 때 보는 것으로 충분하며 그러한 것들을 표시해줘야 할 정도라면 함수의 크기가 너무 커서 불편하다는 것이므로 나누라고 권한다.
단, type정보가 아니라 기능에 대한 정보라면 이름에 포함하는 것이 맞다. (index기능을 하는 변수를 idx_로 시작하기도 한다.)

※ 머리글자 조합 : 각 단어의 머리글자를 따서 이름짓는 방식이다. (예를 들어 SomeTypeWithMeaningfulNaming 라는 이름이 있다면 stwmn으로 줄이는 것이다. 일반적으로는 사전에 나오는 내용으로 구성하는 것이 원칙이다. 하지만 변수가 좁은 범위에서 사용된다면 너무 긴 이름 대신 짧은 이름으로 대치하고 주석을 달아두는 것도 좋다.


함수:
- 동사로 이름 짓는다.

- be, do, perform등과 같은 의미없는 동사의 사용은 피하라.

- 주의 : 사용자의 입장에서 생각하라. 초보자들이 흔히 하는 실수로 함수의 입장에서 이름을 짓는 것이다. 항상 함수를 사용하는 사용자 입장에서 이름을 지어야 한다.  어떻게 해야할지 모르겠다면 왜 이 함수를 만드는지 생각해보자. 적절한 예시가 떠오르지 않는다. 이건 자꾸 연습하다 보면 저절로 될 것이다.

- 주의 : 함수의 내부적인 구현 방법은 생각하지 말고 그 함수의 역할을 생각하라. 함수는 하나의 기능만 가지고 있고 그 기능이 무엇인지에 대해서 이름을 짓는 것이다. 기능을 구현하기 위해 어떤 일을 하건 상관하지 마라. 사과가 몇개인지 알기 위해 사용하는 함수라고 하자. 그럴때 보통 int countApples(); 이런 식의 이름을 지을 것이다. 그러면 사과가 몇개인지만 알면 됐지 이 함수가 재귀호출을 하건 file을 건들건 쓰레드를 만들건 신경쓰지 말라는 말이다.

타입(클레스):
- 클레스 이름은 객체가 아니라 클레스를 묘사해야 한다.(사소하지만 중요한 차이: '사람'이란 클레스 이름대신 '홍길동'이란 클레스 이름을 사용한다면?)

- 상태 값을 가지는 객체를 묘사한다면 명사.

- 함수객체(functor : 함수들 만으로 구성된 객체로 static으로 구현되는 경우가 많다.)거나 가상 call back interface를 구현하는 클레스는 동사 or 잘 알려진 디자인 패턴의 이름

- 클레스가 위의 두가지 성격을 모두 가진다면 이름 정하기가 어렵고, 잘못된 설계일 가능성이 크다.

- DataObject와 같이 당연한 내용을 포함하는 이름은 좋지 않다.(클레스는 data를 포함하는 경우가 많고, 객체화 한다면 당연히 object가 되는 것이 아닌가! 그러니 중복해서 언급할 필요가 없다.) : 좋지 않은 단어 -> class, data, object, type
 

namespace, package:
- 전체적인 내용을 봐라. 이건 꽤 큰 범위라 어휘력에 맡긴다.

- 불필요한 부가적 설명은 피하라 : UI, filesystem, controls등과 같은 이름은 다 좋은 이름들이다. controls_group와 같이 이미 알고있는 내용을 덧붙이지 마라. 길고 쓸데없는 내용은 보기 싫다.

매크로:
= 매크로는 위험하다. (단순 무식 과격하며 힘도 엄청나게 쎄다 : 소스코드가 컴파일 되기 전에 전처리 단계에서 매크로에 해당하는 내용은 모두 지정된 매크로를 거친 값으로 바껴버린다.) 아주 위험하므로 반드시 눈에 띄는 표시가 필요하다.(#define 문을 생각하면 쉽다.)

- 모두 대문자로 표기 (그래야 눈에 잘 띈다)

- 충분히 독특한 이름을 사용해야 한다.(독특한 파일이름이나 프로젝트 이름을 접두사로 붙이는 것이 도움이 될수도 있다. 절대 다른 곳에서 실수로 같은 이름이나 그 이름이 포함된 이름을 사용하면 안된다.)

파일:
- 대소문자에 주의하라. 파일검색은 대소문자 구분을 무시하지만 대소문자를 구분해서 사용하는 곳이 분명히 있다. 책에서는 파일이름을 모두 소문자로 하는 것도 좋은 방법이라고 소개하고 있지만 JAVA에서는 클레스와 인터페이스 이름에 PropreCase를 사용하며 이 이름과 파일 이름이 같아야 제대로 작동한다.

- 헤더파일과 헤퍼의 내용을 구현한 파일의 이름은 같도록 해라. stack.h와 stack.cpp와 같이 쌍을 이루란 말이다.

- 여러 언어를 혼용해서 사용할 경우 같은 이름에 확장자가 다른 것은 같은 디렉토리에 두지 마라. stack.c, stack.cpp, stack.java가 한 디렉토리에 들어있다면 stack.o파일은 뭘 나타내는 것일까? 자식은 하난데 아빠가 셋이다. 가정에 큰일이 날 수도 있다.

- 확장자를 신경써라. C++에서는 확장자를 .C  .cc  .cpp  .cxx  .c++등 여러가지가 있으며 특이하게 헤더파일의 확장자가 .h대신 .hpp로 쓰이는 경우도 있단다. 이런 마구잡이로 쓰인 확장자는 꽤 거슬리는데 MS의 노예가 된 우리는 .cpp와 .h로 거의 통일되어 있다.
more..
대문자 사용의 관례
more..
일관성을 유지하라
- 하나의 이름에 다양한 규칙을 적용하는 바보는 없을 것이다. Using_underscores_AndProperCase 이런거나 Another_Case 같은 이름은 사용하면 안된다는 말이다.

- 프로젝트 전체에 일관된 규칙을 적용해야 한다.
다음과 같은 코드는 일관성이 없어 제대로 분석되기 어려울 것을 예감할 수 있다. more..
콘텍스트 활용
※ 범위(scope)
- 이름의 범위는 global, namespace, class, function(method), loop등 다양하다. 범위에 따라 이름이 조금씩 바뀔 수도 있다는 것을 참고하자. 같은 변수라고 해도 함수내에 사용되느냐 전역이냐에 따라 이름이 다르게 사용되는 예가 가끔 있다.

※ 타입(type)
- 위에서 이미 말했지만 type을 이름에 넣지 말라는 것이 Code Craft란 책의 주장이다. string형식의 변수에 address_string이란 이름을 주어 재언급을 하는 것은 피하자는 것이다. 헝가리언 노테이션은 이런 재언급을 목적으로 하고 있기 때문에 종종 비웃음 산다고 한다.)
그러나
내가 생각하기에 이 책의 저자는 구식 사고방식을 가지고 있는 것 같다. JAVA나 C#등과 같이 다양한 콤포넌트들이 구현되어 있고 그것들을 따와서 사용하는 방식의 프로그래밍은 객체의 형식을 모두 기억하기 어렵다.
윈도우 응용 프로그램을 예로 든다면 form하나에 들어가는 구성요소(label, textbox, button등)의 종류가 많으면 이것들을 다 기억하기 어려울 수가 있다. 대체로 이러한 구성요소들은 form이 생성될 때 같이 생성되어서 form이 사라질 때까지 운명을 함께하기 때문에 scope가 너무 크다. 함수 내에서 사용되는 변수들은 type을 사용하는 것이 오히려 거추장스럽지만 범위가 넓은 경우 이름에 포함시켜 주는 것이 맞는 것 같다.(필요하니까 주장하는 사람들이 있는거다.) 다만 어떤 경우에 type을 적어주고 어떤 경우에 뺄 것인지 명확하게 구분지어 놔야 한다.
scope가 작은 경우 빼는 것이 좋고, 넓은 경우 넣는 것이 좋지만 프로젝트 전체에서 형식을 통일시켜야 일관성이 유지되니 심각하게 고민해봐야 할 사항이다.

(나의 경우엔 type을 적지 않는 편이다. 요즘은 tool들이 좋아서 이름만 있으면 어떤 형식인지 다 알려주기 때문에 그닥 필요하지가 않다. tool에 지배당하고 있는건가?)