꽃 (김춘수)
내가 그의 이름을 불러주기 전에는
그는 다만
하나의 몸짓에 지나지 않았다.
내가 그의 이름을 불러주었을 때,
그는 나에게로 와서
꽃이 되었다.
내가 그의 이름을 불러준 것처럼
나의 이 빛깔과 향기에 알맞은
누가 나의 이름을 불러다오
그에게로 가서 나도...
그의 꽃이 되고 싶다.
우리들은 모두
무엇이 되고 싶다
너는 나에게 나는 너에게
잊혀지지 않는 하나의 눈짓이 되고 싶다.
아마 작가가 한국인이었다면 이 시를 책에 실었을텐데 아쉽다.
요즘은 많이 없어진 것 같지만, 내가 태어났을 때만 해도 한국에는 '작명소'에서 이름을 지어온 이름을 주곤 했다.
그만큼 이름이 중요했기 때문이다.
일생을 살면서 내가 가장 많이 듣는 말이 무엇일까 생각해보면 단언컨데 내 이름이 아닐까 싶다.
만약 내 이름이 '바보'였다면 나는 내가 정말 바보라고 생각한 채로 일생을 살아가야 했을지도 모른다.
'소프트웨어에서도 이름은 어디에나 쓰인다. 우리는 변수에도 이름을 붙이고, 함수에도 이름을 붙이고, 인수와 클래스,
패키지에도 이름을 붙이고...'
소프트웨어에서는 생명주기라는 말을 쓴다.
함수든 클래스든 순간 태어나고 또 죽는다.
그 일생을 책임져 줄 이름을 잘 짓는 것은 그래서 중요한 일이다.
좋은 이름에 몇가지 조건이 있다고 작가는 주장한다.
나 또한 동의하는 몇가지 부분이 많다.
1. 의도를 분명히 밝혀라
존재이유, 수행기능, 사용방법이 이름에 드러나야 한다.
주석이 필요하다면 의도가 명확한지 의심해봐야한다.
2. 그릇된 정보를 피하라
실제로 list가 아닌데 list라는 이름을 포함하는 것은 읽는 사람으로 하여금 헷갈리게 만든다.
3. 검색하기 쉬운 이름을 사용하라
일반적인 글과 조금 다른 면이라고 생각하는데, 우리는 소설과 다르게 읽어나가는 것 뿐 아니라
독자 스스로 고쳐나가고 덧붙이면서 소통한다. 따라서 검색하기 쉬운 이름을 사용하는 것이 중요하다.
4. 자신의 기억력을 자랑하지 마라
나도 알고리즘을 풀다보면 이런식으로 짠 경우가 많았다.
나 혼자 전체 과정을 이해하고(문제를 풀 당시에만..) a,b,c 등의 변수(이름으로 뭐하는 애들인지 나만 아는..) 구조를 만들어 버렸다.
5. 한 개념에 한 단어를 사용하라 + 말장난을 하지 말라
기능당 어휘가 다양해서는 안된다.
fetch, retrieve, get 중에 하나만 골라서 써야한다.
그래야 독자가 혼란스럽지 않다.
그러나 말장난을 하지는 말라고 한다.
유사한 두 개념을 한 단어로 묶지는 말라는 뜻이다.
string의 add를 통해 문장을 더하는 것과
list의 append가 요소를 더하는 것이 같은 더하기라고 하면 안된다.
6. 의미있는 맥락을 추가하라
firstName, lastName, street, city, state, zipcode 라는 변수가 있다면 이것이 주소라는 것을 금방 안다.
하지만 다 읽기 전에도 짐작 가능하게 해주는 것이 좋다.
addrFirstName, addrLastName, addrState 로 쓰면 각각의 변수이름만 봐도 맥락을 읽어낼 수 있다.
써보지는 않았지만 요즘은 괜찮은 변수명을 ide가 작명 해주는 경우도 있다고 하고 좋은 세상이라는 생각이 든다.
이름짓기는 쉽지가 않다.
이름도 글이기에 한 문장이 채 안되는 짧은 단어로 내 의도를 표현하고 맥락을 집어넣기가 쉽지않다.
다행인 것은 프로그램을 짜는동안 언제든 더 괜찮은 이름이 생각나면 개명을 해도 좋다고 작가가 말해준 것이다.
한번 이름지으면 바꾸기가 쉽지 않은 우리와는 다르게 소프트웨어는 이름을 바꾸기가 쉽다니 부담이 덜 한다.
+ 글을 읽다보니 이름들이 대부분 띄어쓰기를 생략, 첫글자를 소문자로 하고 다음 단어부터 대문자로 구분하는 것 같다.
아마 이게 국룰 인가보다.
+찾아봤더니 이런 방식의 작명법이 몇개 있었다.
//카멜케이스
var firstName;
//스네이크 케이스
var first_name;
//파스칼 케이스
var FirstCase
클린코드 읽기