728x90
혼자서만 일하는 프로그래머가 아니라면 레이아웃과 프리젠테이션은 상당히 중요하다.
띄어쓰기 대괄호의 위치 등 사소한 것들이 엄청난 역할을 해준다. 동일한 레이아웃을 구사한다면 사투리가 없는 동일한 언어를 사용하는 것처럼 편안하게 배울 수 있을 것이다.

우리가 작성한 소스를 읽는 대상은 3종류로 볼 수 있다.
우리자신, 컴파일러, 다른 프로그래머(다른 프로그래머가 진짜 독자라고 생각하라.)

좋은 프리젠테이션이란?
1. 일관성있게
   소스파일을 작성하는 도중에 스타일을 바꾸면 안된다. 만약 다른 사람이 작성한 소스를 부분적으로 수정해야 한다면 원래 있던 소스의 스타일을 따르는 것이 좋다. 소스는 처음부터 끝까지 같은 스타일로 코딩되어야 한다.

2. 관례를 따른다
    자기만의 스타일을 고집하지 마라. 자기만의 스타일을 고집하는 사람은 아무도 같이 일하고 싶어하지 않을 것이다.

3. 간단명료(한눈에 들어오는)
    간단 명료하게 하는 것은 중요하지만 길이를 짧게 만든다고 좋은 소스는 아니다. 결국 알아보기 쉽게 작성하는 것이 최우선이다.
728x90
728x90

안전한 데이터를 사용하라
일반적으로 사용하는 배열의 경우 index가 배열의 크기를 넘어설 수 있다는 위험을 안고 있다. 특히 char배열을 사용한 문자열인 경우 쉽게 그 범위를 벗어나는 경우가 많다.
char *unsafe_copy(const char *source)
{
    char *brffer = new char[10];
    strcpy(buffer, source);
    return buffer;
}
책에서 위와 같은 소스를 예로 들었다. 이러한 내용은 다른 데이터구조에 겹쳐 써질 수 있으며 악의적인 사용자에 의해 스택에 실행가능한 코드를 올려놓고 그 코드를 이용해 마음대로 실행시키는 방법으로 사용될 수 있단다. 무섭다. string클레스처럼 관리기능이 있는 버퍼를 사용하라. 그러한 것이 없다면 최소한 strncpy처럼 크기제한이 있는 operation을 사용하라.

모든 리턴 값을 체크하라
printf나 scanf같은 함수들도 리던값이 있다. 모조리 다 체크하라는 것이 아니라 return이 있으면 최대한 활용하라는 것이다.

변수는 선언지점에서 초기화

변수를 가능한 늦게 선언하라
불행히도 C언어처럼 코드 중간에 변수의 선언을 인정하지 않는 언어도 있지만 대부분 중간에 선언하는 변수들도 인정해준다.
1. 반복문 안에 사용하는 변수를 밖에서 선언하지 마라.
for(int i = 0;...)과 같이 사용하라는 말이다.
2. 임시 변수를 여러곳에서 재사용하지 마라.
temp라는 이름의 변수 아깝다고 여기저기서 재사용했던 기억이 난다. 그런거 하나도 아까울 것 없다. 임시변수라고 해도 한곳에서 한가지로 써라.
*** 효율성에 관한 문제는 컴파일러가 처리한다. 컴파일러를 믿어라. 그거 꽤 공부 많이 한 사람들이 머리 싸매고 같이 만든 것들이다.

언어의 표준을 생각하라.
C와 C++이 특히 심하다. 컴파일러마다 표준을 포함하고는 있지만 다른 추가기능들을 보태서 만들어버린다. 표준이 나중에 나와서 그런 것 같다. 심지어는 표준에 맞추어 작동하지 않는 경우도 있다.
컴파일러의 특정한 기능에 의존하면 안돌아가는 코드 만들어놓고 연장 탓하는 프로그래머가 될 수 있다.
우리가 많이 사용하는 MS visual studio 6.0버젼에서는 반복문 안에 선언된 변수가 다른 곳에서 다시 선언되면 에러를 내고 템플릿도 표준에 맞추어 사용되지 않고 있다.

Cast는 신중하게.
대부분의 언어는 타입케스팅을 허용한다. (int)double_num; 이런걸 허용한다는 말이다. 강제로 모양을 바꾸는 것이니 조심해야 한다. 그 순간만 돌아간다고 넘어가면 다른 곳에서 재사용할 때 반드시 문제가 생긴다.

언어의 관용구(idiom)따르기
많은 사람들이 사용하는 단어를 사용하라. 익숙한 말은 오해를 줄여준다.

수치의 범위 체크하기
1. 수치 변수의 오버플로나 언더플로를 조심하라. 확실히 알고 사용하라.
(얼마 전 파일을 byte단위로 달라서 배열에 저장하는 프로그램을 작성한 적이 있었다. 용량이 작은 것은 문제가 없었는데 index범위가 int의 범위를 넘어서자 문제가 생겼다.)
2. 각각의 계산이 완전한지 체크하라. 0으로 나누는 에러등을 생각하라

***********제약***********
1. 배열에 대한 모든 접근이 배열의 범위 안에서 이루어지는지 체크
2. 포인터로 데이터에 접근하기 전에 포인터의 값이 NULL인지 확인
3. 객체에 대한 operation을 하기 전에 그 객체의 상태에 모순이 없는지 증명
(연산자 오버로딩을 할 경우 연산자 양쪽에 각은 객체가 있을 경우도 생각해야 한다.)
4. 파라미터와 리턴값을 제대로 확인하자.

728x90
728x90
사용자 삽입 이미지
역시 내 머리는 체계적이지 못해서 'Code Craft'란 책의 힘을 빌리기로 했다. 그런데 이거 원서를 읽기는 부담스럽고 번역서를 읽자니 번역이 엉망이다. 일단 샀으니 열심히 보겠다만 번역한 사람이 어디서 굴러먹던 프리렌서인지 몰라도 번역 후 자기 글을 얼마나 열심히 읽었는지 알 수가 없다. 내용은 좋은 책이니 나한테 필요한 부분만 골라서 열심히 정리해보자

기본 습관 : 에러체크, 테스트, 디버깅
에러체크 : 코드를 작성하는 도중에 발생가능한 에러를 체크하고 막는 과정
테스트 : 발생가능한 에러가 있는지 찾아보는 과정(일단 테스트할 부분은 완성되었다고 가정)
디버깅 : 찾아낸 에러를 수정하는 과정이다.(말 그대로 버그잡기, 글로 따지면 퇴고다.)

코드 작성을 서두르지 마라.
gotcha : 문법적으로는 맞지만 원하는 것과 다르제 작동하는 것. ==를 =로 잘못 타이핑 하는 것등.

아무도 믿지마라.
당신의 코드가 사용되는 곳은 다음과 같다
* 우연히 엉터리 데이터를 입력하거나, 프로그램을 잘못 작동하는 정직한 사용자
* 의식적으로 프로그램에 오작동을 일으키는 악의적인 사용자
* 잘못된 파라미터(주1)를 가지고 함수를 호출하거나 모순된 데이터를 입력하는 클라이언트 코드
* 프로그램에 적절한 서비스를 제공하지 못하는 실행환경(OS등)
* 오작동을 하거나, 당신이 의존하는 인터페이스 규격을 따르지 않는 외부 라이브러리

짧은 코드가 아니라 명료한 코드를 작성하라
코드는 한눈에 들어와야 한다. 함수나 method는 20~30줄을 넘지 않는 것이 좋다. 그렇지만 짧다고 좋은 코드는 아니다. x += ++y; 이딴 식의 복잡한 수식은 절대 쓰지마라.
++y;
x = x + y;
이렇게 두줄이면 충분할 것을 괜히 줄인다고 복잡한 수식을 사용하면 알아보기가 어렵다. 당신이 연산자 우선순위를 잘 알고있다는 것은 자랑할 수 있지만 아무도 같이 일하려 들지 않을 것이다. 극단적인 경우 지나치게 복잡한 연산식 때문에 컴파일러가 잘못된 코드를 생성할 수도 있다.(최적화 과정에서 발생하는 에러는 이러한 경우가 많다. 컴파일러를 거치고 난 어셈블러를 분석해보면 원래코드랑 조금 다른 것을 볼 수 있다. 그건 최적화를 거쳐서 그렇다.)

어설프게 만지면 안되는 것은 아무도 못 만지게 하라
* 객체지향언어에서는 맴버변수를 모두 private로 한다.
* 모든 변수는 그 변수가 속할 수 있는 가장 좁은 범위(scope)안에 둬라.
-- 무지하게 잘난 인간이 아니면 전역은 쓰지마라.
-- 루프안에 선언해도 되는 변수는 루프안에 선언해라.
-- method 내에서만 사용해도 되는 변수를 맴버변수로 올리지 마라.

경고를 무시하지 마라.
컴파일하면 경고(warning)이 뜨는 경우가 있다. 위험하다고 경고하는 거다. 그냥 넘어가면 안된다.
만약 특정 경고가 당신에게 중요치 않더라도 그대로 두지 마라. 나중에 그로인해 정말 중요한 경고가 눈에 안 띄게 될수도 있다.
728x90

+ Recent posts