프로그래밍을 하다보면..
변수명때문에 고민하는 경우가 참 많다..
같은 변수명인데도.......프로그램이나 모듈마다 다르고..
결국 프로젝트가 커지면 커질수록...
암호화 되어가는 코드가 생겨나는 것이다..
주석을 잘 단다면......그나마 낳기는 하겠지만..
주석으로 인해서 코드가 지져분해지는 모습은...
개인적으로 너무 싫다..
그래서 데이터 용어사전의 필요성에 대해서..생각을 하게 되었다.
우선은 헝가리안 표기법을..기본으로 하여야 한다.
그리고 내가 정한 방식이므로 꼭 이렇게 해야 한다는 말은 아니다..
단순한 참고 자료가 되었으면 한다...
Long 형은 접두어로 l 을
INTEGER 형은 접두어로 n 을 (i를 하지 않은 이유는 l과 비슷해 보이기 때문에..)
String는 z 를 (s는 전문에서 쓰고자..빼두었다..)
Char은 c를
전문용 String은 s를 (전문은 통..String으로 이루어진..데이터를 의미한다.)
Date형은(DB에서 사용)은 d를
대충 이렇게 접미어를 정의해 두고...
데이터 용어 사전을 만든다.
등록 : Reg (Regist)
글 : Cnts (Contents)
날짜 : Dt (Date)
.
.
.
.
Excel이나 DB로 이런 사전을 관리하면서 필요시마다 찾아 볼 수 있도록 해야 한다.
프로젝트 규모가 클수록 DB가 좋을 것이다..(동기화 문제.)
이런 사전이 있으면..
글등록일 이라는 변수명은... dCntsRetDt 형태로...
용어사전에 맞는 변수명을 만든다..
이렇게 정의된 형태의 변수명만 사용한다면..
자주 사용하는 변수명은 외우게 되어...
바로바로 쓰고 알아보게 될 것이고..
자주 사용하지 않는 변수명이라면....
바로바로 검색하여 변수의 의미를 알게 될 것이다..
단점이라면...
데이터 용어사전 만드는데...드는 노력과...
데이터 용어사전을 관리하는 어려움...등이 있겠지만..
프로젝트의 규모가 커지면 커질 수록 유용하며..
유지보수에도 아주 큰 도움이 될 것이다.
그리고 자주 쓰는 변수명(DB컬럼 포함)들은..
따로 관리를 하고...char[]의 경우는...
사이즈도 정하는 것도.....좋은 방법인듯 하다.
