(갑자기 곁가지이지만 초안이니까요 뭐-.- 나중에 좀 더 고민이 성숙되어서 ‘문장론’을 쓸 수 있게 된다면 이 절은 문장론의 일부가 될 것입니다.)
문장이 구문적으로 옳다는 말은 간단히 말하면 문법에 맞는다는 이야기이다. 이를 적격성(well-formedness)라고도 한다. 의미론적으로 옳다는 것은 말이 된다는 뜻이다. 이를 유효성(validity)라고도 한다. 예를 들어서 “Time flies like an arrow.”는 구문적으로나 의미론적으로나 문제가 없지만, “Thyme flies like an arrow.”은 구문적으로 옳으나 의미론적으로는 좀 이상하다(thyme은 향신료-.-).
올바른 문장은 구문적으로도 옳아야 하고 의미론적으로도 옳아야 한다. 대부분의 프로그래밍 언어들은 의미론적으로 옳으려면 구문적으로도 옳아야 한다. 즉 적격성은 유효성의 전제 조건이다. 반면 자연 언어는 그렇지 않은 경우도 있다. 예를 들어 ‘날으는 비행기’는 구문적으로 옳지 않지만(‘나는 비행기’가 옳다) 뜻은 통하기 때문이다.
컴파일 언어로 된 프로그램 문장의 구문적 정확성은 컴파일 시점에서 판단된다. 반면 의미론적 정확성은 실행 시점에서 판단된다. 구문적으로 정확하지 않은 문장은 컴파일 오류(소위 신택스 에러)를 내며, 이는 잡아내기 쉽다. 의미론적으로 정확하지 않은 문장은 버그 또는 논리적 오류가 되며, 컴파일 오류에 비해 잡아내기 어렵다.
오류를 피하고 디버깅을 줄일 수 있으려면 구문적 정확성이 의미론적 정확성을 최대한 보장해 줄 수 있어야 한다. C++처럼 형식(type)에 엄격한 언어는 그러한 보장이 비교적 쉽다. 이는 C의 printf()와 C++의 cout 을 비교하면 쉽게 이해할 수 있다.
표준 C 라이브러리의 함수 printf()의 원형은 다음과 같다.
int printf(const char* format, ...) ;
첫 번째 매개변수만 형이 정해져 있고 그 다음부터는 가변인수들이다. 이는 구문적으로 옳지만 의미론적으로는 옳지 않은 문장에 대한 어떠한 보호도 없다는 뜻이다. 예를 들어:
printf("결과: %s", s);
이러한 문장은 s가 널 종료 문자열일 때에만 안전하다. 이 문장 자체는 구문적으로 옳지만 s가 널 종료 문자열이 아니면 의미론적으로 옳지 않게 된다.
반면 cout은 구문적 정확성이 의미론적 정확성을 (어느정도)보장한다.
cout << "결과:" << s;
만일 s가 int라면 s의 값이 문자열로서 출력된다. 널 종료 문자열이라면 s에 담긴 문자열 자체가 출력된다. s가 어떤 구조체나 클래스의 객체라면, 그 클래스가 << 연산자를 지원한다면 그에 맞게 출력이 되고 그렇지 않다면 컴파일 오류가 생긴다. 즉 의미론적으로 옳지 않은 문장이 구문적으로 거부되는 것이다.
변수, 함수 이름을 제대로 붙이고 영어 문장을 염두에 두면서 코드를 만드는 것은 구문적으로 옳은 코드가 의미론적으로도 옳은 코드가 되게 하는 데 일정한 도움이 될 것이다.
(!!이 부분에서 좀 더 구체적인 사례가 필요!!)
10. 어휘
어휘는 간단히 말하면 단어, 숙어들의 집합이다. 프로그램의 어휘는 곧 프로그램에 쓰인 식별자들(클래스, 변수, 상수, 함수 등등의 이름들)의 집합에 해당한다.
프로그래머는 어휘가 풍부해야 하나 자신의 어휘력을 자랑할 필요는 없다. 어휘가 풍부하다는 것은 해당 언어의 키워드들이나 표준 라이브러리의 함수, 클래스들을 잘 알고 있다는 뜻이다. 예를 들어서 for만 알고 while을 모르는 사람이나 printf만 알고 cout은 모르는 사람보다는 둘 다 아는 사람이 더 나은 코드를 만들 수 있을 것이다.
반면 어휘가 풍부하다고 해서 한 프로그램에서 필요 이상으로 많은 종류의 단어들을 집어 넣을 필요는 없다. 예를 들어 서로 다른 자료형들에 대해 동등한 일을 하는 함수라면 같은 이름을 붙이고 매개변수 목록에만 차이를 두어서 중복시키면 된다.
일상 언어와 마찬가지로, 프로그래밍 어휘는 무한하다. 이는 대부분의 프로그래밍 언어들이 변수라는 개념을 지원하며, 또한 사용자 정의형이나 사용자 정의 함수를 지원하기 때문이다. 역시 일상 언어로 쓰여진 책이나 문서에서처럼, 특정한 한 프로그램 안에서의 어휘는 유한하다. 대부분의 프로그래밍 언어들에서 식별자들은 이미 소스 코드가 작성될 때 고정되기 때문이다. 대체로 프로그래밍에서는 (비유하자면)간결체, 건조체 같은 문체들이 선호되므로, 좋은 프로그램은 ‘풍부한 어휘 중에서 꼭 필요한 낱말들만으로 만들어진’ 프로그램이라고 할 수 있다.
11. 함수에 자주 쓰이는 동사들
함수들은 쓰임새에 따라 크게
1. 뭔가를 돌려주는 함수
2. 객체의 상태를 변경하는 함수
3. 외부 시스템에 대해 뭔가를 수행하는 함수
로 나눌 수 있다.
예를 들어 GetDC()는 1번, SetDC()는 2번, DrawText()는 3번에 해당한다고 할 수 있다. 물론 하나의 함수가 세가지 종류 중 둘 이상에 해당하는 경우도 있으며, 그런 경우 가독성을 위해서는 함수 이름에 둘 이상의 동사들이 들어가거나(예: SetCursorPositionAndDrawText(x, y, str) 등), 아니면 개별적인 함수들로 분리해야 할 것이다(SetPosition(x, y) ; DrawText(); )
1. 뭔가를 돌려주는 함수에 주로 쓰이는 동사들(이하 돌려주는 동사)
가장 대표적인 동사는 get이다. 그런데 왜 return이 아닌가? 한 가지 이유는, return은 실행 흐름의 제어에 관련된 뜻으로 쓰이는 경우가 많기 때문이다. 또 다른 이유는 주어를 무엇으로 볼 것인가의 문제이다. 주어가 객체 자체라면 return이 더 자연스럽겠지만, 등호 왼쪽(lhs)의 변수를 주어로 본다면 get이 더 자연스럽다..
예:
Result = Vector1.returnSize(); // Vector1이 자신의 크기를 Result에게 '돌려준다'.
Result = Vector1.getSize(); // Result가 Vector1의 크기를 '얻는다'.
* get - 가장 흔히 쓰이며 의미하는 범위도 가장 넓다. GetDC(), getInstance(), getPosition() 등등. get은 아래에 나열된 다른 모든 돌려주는 동사들을 포괄한다. 그러나, get의 용도를 최대한 한정시킨다면 주로 ‘이미 계산되어 있는 객체의 속성 또는 시스템의 특정 상태를 돌려주며 상태, 시스템을 변경하거나 어떠한 복잡한 처리를 하지 않는’ 함수에 쓰는 것이 좋다고 본다.
* retrieve - get에 비해 이것은 반환할 결과를 찾기 위한 처리(주로 검색)가 일어남을 암시한다. 필요하다면 이 동사는 search 같은 실제 수행 동사와 get으로 나눌 수 있다.
* acquire - 제한된 자원을 독점적으로 확보한다는 뜻이 있다. 예를 들어 주어진 윈도우 또는 시스템 전체에 DC가 하나이며 GetDC()로 얻은 DC를 ReleaseDC()로 풀기 전까지는 혼자만 사용해야 하는 상황이라고 하자. 그런 경우라면 GetDC() 보다는 AcquireDC()가 더 적합하다. 반환값은 확보한 객체 자체나 포인터, 핸들 등이다. 반대말은 release나 unacquire(get에 대해 release를 사용한다면 acquire에 대해서는 unacquire를 사용해서 구분해 주는 것이 좋을 것임).
* fetch - 돌려준 값을 담고 있는 컨테이너의 내부 상태가 변함을 의미한다. 주어진 컨테이너 안의 어떤 값을 가져오면 현재 값의 위치를 가리키는 포인터가 다음 값으로 이동하게 되는 경우에 fetch가 쓰인다. 데이터베이스 API에서 흔히 볼 수 있다. 스택의 pop과도 비슷하다. 또한 파일 시스템의 많은 함수들이 이러한 fetch 식으로 작동한다. 이는 moveNext와 get으로 분리될 수 있다.
* be 동사와 조동사 - 이들은 어떠한 상태 또는 여부를 뜻하는 부울 값을 돌려줄 때 주로 쓰인다.
예:
while ( isDone ) {
if ( currentUnit.hasWeapon() ) ....
....
}
2. 객체의 상태를 변경하는 함수에 주로 쓰이는 동사들
객체 또는 현재 범위의 어떤 값을 변경하는 함수들에 가장 흔히 쓰이는 동사는 set이다. 이런 동사들은 반환값이 없거나 또는 함수의 성공 여부를 알려주는 반환값을 가진다.
또는 변경되기 전의 상태나 변경된 후의 상태를 돌려주기도 하는데(Win32 API의 SelectObject() 등) 코딩의 양을 줄이는 데에는 좋지만 가독성 면에서는 혼란의 여지가 있다.
상태를 변경하는 함수에 쓰이는 동사들의 종류는 돌려주는 동사보다 훨씬 더 많다. 이는 상태를 변경하는 함수의 동사는 그 상태가 어떤 종류의 값인 지, 그리고 그 상태를 변경하는 데 어떤 작업이 필요한 지에 따라 얼마든지 다양해질 수 있기 때문이다.
따라서 사실 ‘주로 쓰이는’이라고 할만한 동사는 set 정도이다.
* set - 가장 흔하게 쓰인다. 설명이 필요없겠지만 굳이 부연 설명을 하자면, get의 반대물이라는 차원에서, 상태의 변경에 복잡한 처리가 일어나지 않는 비교적 단순한 코드로 된 함수에 적합하다.
3. 외부 시스템에 뭔가를 수행하는 함수에 주로 쓰이는 동사들
2번과 마찬가지로, 수행하는 작업이나 외부 시스템에 따라 다양한 동사들이 쓰이므로 주로 쓰이는 동사들이라고 할만한 것은 없다. 다만 게임의 경우 외부 시스템이 주로 그래픽, 오디오, 입력 장치들이므로 굳이 고른다면 몇 가지를 고를 수 있을 것이다.
그래픽 시스템
display - 실제의 시각적 변화를 일으킨다는 의미가 있다(버퍼 스왑 등 실제 비디오 메모리 갱신의 차원에서). 또는 아래의 동사들을 포괄하는 고차원 함수에도 쓰인다(특정 그래픽 API에 국한되지 않는...)
render - display와 비슷하나 내부 버퍼 메모리의 갱신만 의미할 수도 있다. 즉 render 후 상황에 따라 display가 수행되는 등. render부터는 특정 그래픽 API에 국한된 함수에 가까와진다. 목적어를 가질 수 있다(renderScene, renderBackground 등)
draw - 개별 데이터나 개별 개체를 그린다는 의미로 많이 쓰인다. Model.draw()나 drawText() 등. render 안에서 일어나는 경우가 많다.
put - 주로 2D에서 점이나 스프라이트를 ‘찍는다’는 의미로 쓰인다. 실제의 시각적 변화보다는 내부 메모리에서의 변화일 가능성이 크다. 3D에서는 별로 쓰이지 않음. 목적어를 가지는 경우가 많다(putPixel, putSprite 등)
flush - 그래픽이나 장면 데이터를 스트림으로 간주할 때 쓰인다. 지금까지 명령 버퍼 또는 프레임 버퍼에 쌓여 있는 데이터를 실제 장치로 밀어 내보낸다는 의미를 가진다.
오디오 시스템
play - 말 그대로 재생. 대상은 출력 버퍼보다는 음악, 음성 데이터를 감싸고 있는 좀 더 고차원의 객체일 가능성이 많다. 무엇을 재생하는가에 따라 목적어를 가질 수 있다(playSFX, playMusic 등).
perform - play보다 좀 더 고수준. ‘연주’를 뜻한다. 따라서 이 동사의 대상은 음성 데이터 차원보다 높은 연주 정보를 담는 객체가 될 것이다.
output - play 보다는 저수준. 바이트 차원의 파형 정보를 출력 버퍼로 내보내는 경우.
입력 장치
입력 장치의 특성 상 입력 장치에 대해 뭔가를 수행하는 경우는 별로 없고 입력 장치로부터 정보를 얻는 것이 대부분이므로 앞에서 말한 돌려주는 동사들이 주로 쓰인다. 예외는 진동 기능(force-feedback)일 것이다.
4. 애매한 동사들 - 돌려줄 것인가 말 것인가
예를 들어서 기본 대미지와 타격 가능성으로 실제 대미지를 계산하는 calculateDamage(BaseDamage, HitProbability)라는 함수가 있다면, 계산된 실제 대미지는 어디로 가야할까? 두 가지 가능성이 있다.
가끔가다가..
명사나 형용사로 함수명을 지어야 할때가 있습니다.
무엇무엇과 같은것을...해라..
음 단순한 동사로 했다가는 의미가 애매해지는 경우를 말하는것이죠..
그럴때는 저의 경우는 Do를 앞에 써줍니다.
행동을 해줘야 한다는걸 강조해 주는거죠..
벽깨는 동작을 해라.. 라고 할때 BreakTheWall을 하면..
벽을깨는거지만.
DoMotionBreakingTheWall 이라고 하면 벽깨는 동작을 해라 라고 하게 됩니다.
혹은.. bool값을 반환하는 단순상태의 경우는 Is나 Does를 앞에 써줍니다.
이런 펑션을 If문 안에 써주면 주석을 쓰지않아도 의미가 명료해 집니다.
GetBound?? 이런건 이름자체가 잘못된거지만.. bool을 이렇게 쓰면 웃길때가 있다고 치고
IsInsideBound 는 명료하게 참거짓을 쿼리하는거라는 인식을 하게 하죠..
음... 이건 제 습관이라서... 많은 공격 바랍니다.
FAQ
검색
멤버리스트
사용자 그룹
이미지 자료실
사용자 등록하기
개인 정보
쪽지(개인 메시지)를 확인하려면 로그인하십시오
로그인
[?]
