. 기능 정리

버전 1.0을 만들기까지 프로젝트를 약 30개 정도 만들었다. 프로젝트 하나를 새로 만들 때마다 한꺼번에 여러 개의 기능들이 추가되었으므로 만들어온 기능대로 실습 단계를 나눈다면 100단계 정도 될 것 같다. 1.0까지 어떤 실습을 해 왔고 당근의 기능에는 어떤 것들이 있는지 정리해보도록 하자. 다음 표는 당근의 단축키를 정리한 것인데 이 표에 대부분의 기능들이 모두 들어 있다.

 

Ctrl

Ctrl+Shift

Alt

A

모두 선택

 

 

B

괄호짝찾기

괄호까지 선택

 

C

복사

복사하여 추가

 

D

 

 

 

E

제어코드 보기

 

편집 메뉴

F

찾기

파일 찾기

파일 메뉴

G

줄찾기

 

 

H

 

 

도움말 메뉴

I

윗줄문자 반복

아래줄문자 반복

 

J

 

 

 

K

 

 

 

L

소문자로

 

 

M

주석으로

주석제거

 

N

새파일

 

 

O

열기

 

 

P

인쇄

 

 

Q

마지막편집위치로

 

 

R

바꾸기

 

 

S

저장

모두 저장

검색 메뉴

T

기본설정

 

도구 메뉴

U

대문자로

 

 

V

붙여넣기

 

 

W

자동개행

 

메뉴

X

잘라내기

잘라서 추가

 

Y

재실행

 

 

Z

취소

 

 

1~0

이름있는 북마크 이동

이름있는 북마크 지정

 

 

단축키는 주로 알파벳과 숫자를 사용했으며 기호는 일체 사용하지 않았다. 괄호 짝찾기는 통상 <Ctrl+]>키가 사용되는데 당근이 이 키를 채택하지 않은 이유는 비주얼 C++ 6.0 7.0에서 비표준 액셀러레이터를 취급하는 방식이 조금 달라서이다. 펑션키는 F2, F3 두 개만 사용하며 나머지는 비어 있다.

 

 

단독

Ctrl

Shift

Ctrl+Shift

F2

다음 북마크

북마크 토글

이전 북마크

 

F3

다음 찾기

다음 단어

이전 찾기

이전 단어

 

단축키 목록에는 없지만 네트워크 지원, 포맷변환, 변경 감시, 프로젝트, 문법강조 등의 기능들도 작성되어 있다. 그러고 보면 꽤 많은 기능을 작성해 왔는데, 이 기능 목록은 최초의 기획보다는 훨씬 더 많이 작성한 것이다. 이 예제는 교육용 버전이라는 특수성이 있어서 편집기를 만드는 핵심적인 방법에 대한 설명 위주로 기능을 구성하고자 했는데, 자꾸 하다 보니 너무 멀리까지 온 것 같다.

비록 당근이 1.0이라는 버전 번호를 붙이고 일단락되기는 했지만 안정화 수준에 대해서는 자신있다고 말할 수 없다. 모든 프로그램에 버그가 있듯이 당근도 당연히 아직 찾지 못한 버그가 있다. 최고의 개발자가 최선의 노력으로 작성한 소스는 1000줄당 0.5개의 버그가 있다고 할 정도니 당근은 최소한 20개 정도, 아마 100개 이상의 버그를 가지고 있을 것이다. 실습중에 혹시 버그가 보이면 너무 나무라지 말고 애교로 봐주기 바란다. 나름대로 친구, 후배들을 괴롭혀 가며 열심히 디버깅을 했는데 이 모양이다. 좀 더 안정화된 모습을 갖추기 위해서는 실제 사용자들을 대상으로 필드 테스트를 해야 한다.

알고 있는 버그(Known Bug)도 사실 몇 가지 있다. 예를 들자면 문서 포맷이 혼합되어 있거나 일부가 잘려 나간 텍스트는 읽지 못하며 잘못하면 죽을 수도 있다. 2바이트 문자의 경계 부분이 문서의 끝이면 문서 끝을 찾지 못하는데 아주 희귀한 경우이지만 다음 버전에서는 분명히 해결해야 한다. 설계상의 문제점이 있는 부분도 있는데 FTP 서버의 파일을 다운로드/업로드는 할 수 있지만 새로 파일을 만들지는 못한다. 이 문제를 해결하려면 결국 기본적인 FTP 클라이언트 기능을 수행할 수 있도록 기능을 확장해야 한다.

또 한 가지 소스가 너무 개인적이라는 점에 있어 양해를 구하고 싶다. C 컴파일러는 프리포맷을 지원하기 때문에 문법에만 맞으면 소스의 형식에는 제한을 두지 않는다. 그래서 소스의 포맷이 전문적이지 못하고 늘 하던 방식대로 작성하다 보니 눈에 거슬리는 부분이 많이 있을 것이다. 변수나 함수의 이름을 정하는 것은 아주 힘든 일인데 별다른 형식없이 편한 대로 이름을 붙였다. 소스의 깔끔함을 좋아하는 사람들은 이름을 붙이는데도 상당한 시간을 투자하지만 나는 성격상 그런 작업에 시간을 쓰고 싶지 않았다.

띄어쓰기도 일관성이 없는데 인수와 콤마, 연산자와 피연산자 사이의 여백을 잘 조절하지 못했다. a+b로 쓰는 것이 습관화되어 있다 보니 a + b로 쓰면 왠지 어색해보인다. 소스의 포맷에 대한 절대적인 법칙은 없지만 최소한 일관되게 지켜 주는 것이 좋으며 여러분들은 나름대로 자신만의 규칙을 만들어 지키기 바란다. 실행파일은 결과로만 평가되지만 소스는 그 형식으로도 평가되기 때문에 자신이 만든 소스를 남에게 전부 다 보여 준다는 것은 참 부끄러운 일인 것 같다.

함수이름이나 띄어쓰기 규칙, 모듈배치, 블록 구조 등에 대한 원칙을 마련하고 일관되게 지켜야 한다. 특히나 여러 명이 같이 하는 프로젝트일 경우는 이 문제가 아주 중요하다. 당근은 그렇게까지 하지는 못했는데 기획부터 테스트까지 혼자 하는 프로젝트인데다가 보다시피 단계별로 작성되어 있는 예제들을 전부 다 고치기가 너무너무 어렵기 때문이다. 그럴 시간이 있으면 차라리 오타나 하나 더 잡는 것이 중요하다고 판단했다.