예외를 사용 할 시기

언제 예외를 사용해야 하는가?

예외가 발생하지 않는 상황에서만 예외를 사용하라. 주기적으로 루프를 종료하면 서 ArrayIndexOutOfBoundsException를 발생시킬 수 있다. 그리고 아무 일도 없는 것처럼 예외가 발생한 메소드에서 표준 결과값을 넘긴다.

스레드에 떠넘기라

제목 그대로 행동하라.

변호사 코드

뉴스 그룹에서 까다로운 코드가 어떻게 수행돼야 하는지를 두고 논쟁을 하는 경우 가 있다(예를 들어, a=a++;, f(a++,a++);). 이와 같이 논쟁이 벌어지는 코드를 우 리 프로그램에 자유롭게 사용하자. 아래와 같은 선/후 감쇠 코드를 어떻게 처리해 야 하는지는 언어 스펙에서 정의하지 않는다.

*++b ? (*++b + *(b-1)) 0

따라서 컴파일러마다 각자 임의로 위 수식을 평가한다. 비슷한 방법으로 모든 공백 을 없애서 C와 자바의 복잡한 토큰화 규칙을 이용할 수도 있다.

중간 반환문

goto를 사용하지 않고, 중간에 반환하지 않으며, label을 사용하지 않는다는 규칙 을 엄격히 지켜야 한다. 그러나 우리가 최소한 5단계 이상으로 중첩하는 if/else문 을 만들 수 있다면 이 규칙을 꼭 지키지 않아도 된다.

avoid { }

문법적으로 어쩔 수 없는 경우가 아니라면 절대로 if/else 블록을 감싸는 괄호 { }를 사용하지 말자. 들여쓰기 없이 if/else와 블록을 여러 단계로 중첩한다면 전문 유 지보수 프로그래머라도 가볍게 해치울 수 있다. 펄Perl을 사용하면 이 기법의 효과 가 극대화된다. 일반 코드 뒤에 if문을 양념으로 추가하는 것도 좋은 방법이다.

지옥에서 온 탭

탭을 과소평가하지 마라. 탭이 얼마의 공간을 나타내야 하는지에 대한 표준이 없는 회사에서는 공백 대신에 탭을 사용하므로 큰 혼란을 야기할 수 있다. 스트링 문자 에 탭을 추가하거나 공백을 탭으로 변환해주는 툴을 돌리는 것도 좋은 방법이다.

마법 같은 행렬 위치

특정 행렬 값을 플래그로 사용해보자. 변환 행렬에서 동종 좌표 시스템을 이용한 [3][0]에 위치한 요소 등은 좋은 예이다.

마법 같은 행렬 슬롯의 개선

주어진 형식의 여러 변수가 필요할 때에는 변수를 배열로 정의하고 숫자로 각 변수 를 접근할 수 있다. 이 때 숫자 규칙은 자신만이 아는 것으로 정하고 문서화하지 않 는다. 또한 고생스럽게 #define 상수로 인덱스를 정의할 필요도 없다. 전역 변수 widget[15]는 취소 버튼이라는 사실은 누구나 당연히 알고 있어야 한다. 이는 어 셈블러 코드에서 절대적 숫자 주소를 접근할 때 최근 이용하는 방식이다.

아름다움을 멀리하라

절대 자동 코드 정렬 기능으로 코드를 정렬하지 말자. PVCS/CVS(버전 관리를 이 력을 추적하는)에서 가짜 정보를 만드는 이와 같은 도구를 사용하지 않도록 회사 현장에서 로비를 하자. 또는 모든 프로그래머는 자신이 만드는 모듈에 영원히 신성 불가침한 자신만의 들여쓰기 방식을 가져야 한다고 주장하자. 다른 프로그래머에 게는 이러한 방식을 따르더라도 각자가 만든 모듈에서만 이와 같은 특유의 규칙이 나타나므로 별로 신경 쓸 일이 아니라고 설득하자. 아름다움을 멀리하는 방법은 간 단하다. 아름다움을 멀리하므로 수동 정렬로 인한 수백만 번의 키 입력을 아낄 수 있고, 정렬이 엉망인 코드를 오역하는 바람에 며칠을 낭비하는 일도 사라진다. 공 통 저장소에 코드를 저장할 때뿐 아니라 편집할 때에도 모두가 같은 정렬 형식을 사용해야 한다고 주장하자. RWAR과 상사를 먼저 설득하자. 아마도 평화를 위해 자동 정렬 기능은 사용 금지될 것이다. 자동 정렬이 금지되었으면 루프나 if문의 바 디가 실제보다 길어 보이거나 짧아 보이게 정렬할 수 있다. 혹은 else 문을 다른 if 와 연관되는 것처럼 보이게 할 수도 있다. 물론 모든 일은 우발적으로 일어나는 것 일 뿐이다.

매크로 전처리기

매크로 전처리기는 코드 난독화를 할 좋은 기회를 제공한다. 핵심은 매크로 확장을 여러 단계에 거쳐 확장하고 여러 *.hpp 파일을 이용해야 뜻을 파악할 수 있게 만 드는 것이다. 실행할 코드를 매크로에 넣은 다음 모든 *.cpp 파일에서 이 매크로를 가져다 사용하므로(매크로를 쓰지 않더라도 이렇게 하는 것이 좋다) 코드가 변경될 때마다 다시 컴파일해야 할 코드 양을 극대화 할 수 있다.

 

일관성 부족을 악용하라

자바에서 배열 선언은 정말 어지럽다. 예전 C 형식으로 할 수 있고, string x[]와 같은 방식도 가능하며(배열 표시 위치가 앞-뒤로 혼합된 형태), string[] x(배열 표시가 앞쪽에 오는 형태)와 같이 선언할 수 있다. 사람들에게 혼란을 주려면 다음 과 같이 여러 표기법을 혼합한다.

 

가짜(pseudo) C

#define의 본래 목적은 다른 프로그래밍 언어에 익숙한 사람이 C로 쉽게 변환할 수 있도록 하는 것이다. 따라서 #define begin { “ 또는 “ #define end }과 같은 선언문을 이용하면 아주 신선한 코드를 쉽게 만들 수 있다.

혼란을 안겨주는 import

패키지에서 우리가 어떤 메소드를 사용하는 것인지 유지보수 프로그래머에게 직접 알려주지 말고 추측하게 할 수 있다. 즉 아래와 같이 명시하지 말고,

import MyPackage.Read; import MyPackage.Write;

이렇게 사용한다.

import Mypackage. *;

절대, 클래스나 메소드에 패키지명을 포함한 전체 이름을 사용하지 않는다. 유지보 수 프로그래머가 우리 코드를 보면서 각각 어떤 패키지/클래스에 속한 것인지 추 측하게 만들자. 물론 경우에 따라 전체 패키지 이름을 사용하거나 import 구문 사 용방식을 바꾸어 주면 더욱 효과적이다.

변기 배관

어떤 경우에도 함수나 프로시저가 한 화면에 모두 보이도록 하지 말아야 한다. 간 단한 루틴에는 아래 설명하는 기법을 사용하자.

일반적으로 코드의 논리적인 블록을 구분하는 데 빈 줄을 사용한다. 우리 코드의 모든 라인은 각각이 논리적인 블록이다. 따라서 모든 줄에 빈 줄을 추가한다.

주석을 코드 끝에 추가하지 말고 윗부분에 추가하라. 어쩔 수 없는 강요에 의해 코 드의 뒷부분에 추가해야만 하는 상황이라면 전체 파일에서 가장 긴 줄을 찾아 10 개의 공백을 넣고 모든 end-of-line 주석을 왼쪽 정렬한다.

프로시저 윗부분의 주석에 사용할 템플릿은 적어도 15줄 이상이어야하고 빈줄도 자유롭게 추가한다.