큰 프로젝트에서 프로그램 네이밍 관련
글쓴이: imgromit / 작성시간: 목, 2005/12/22 - 9:34오전
안녕하세요...
금융권에서 대규모 프로젝트에 참여하고 있습니다.
개발환경은 Unix/C 입니다.
현재 개발표준화가 진행되고 있는데,
프로그램 함수 명명규칙에 관해 궁금한게 있습니다.
예전에 COBOL 접해보셨던분들은 익숙하실것 같은데요.
함수명을
A000_MAIN
B000_INPUT_CHECK
C000_INSERT_PROCESS
C100_DELETE_PROCESS
D000_ERROR_PROCESS
처럼 정의하려고 하는데,
이런 표기(xnnn 으로 함수의 depth를 표기하는 것)가
C에서 일반적인지 알고 싶습니다.
Open Source 내에서는 저런 표기를 전혀 찾아볼 수 없는데..
대규모 프로젝트에 저런 표기를 쓰시나요? (C 환경에서)
여러분의 의견을 듣고 싶습니다.
Forums:
depth란 게 뭘 나타내는 거죠?
얼핏 봐서 딱히 떠오르는 개념이 없는데, 함수의 depth라는 게 뭔가요?
전혀 일반적이지 않지만, 약속이 그러하다면 이유를 들어 보고 적응하시는
전혀 일반적이지 않지만, 약속이 그러하다면 이유를 들어 보고 적응하시는 것이 좋습니다. :)
네이밍 같은 것에 목숨거는 것 보다 알고리즘에 집중하시는 것이 경험상 더 좋습니다.
---
http://coolengineer.com
함수의 depth 는 제가 표현을 잘 못한것 같습니다.[code:
함수의 depth 는 제가 표현을 잘 못한것 같습니다.
main - level 000 validate_something - level 100 validate_more_thing - level 110 validate_moremore_thing - level 120 process_somthing - level 200이런식인 경우 함수간 계층관계를 말하려 했던건데, 표현이 서툴렀습니다.
회사의 특성인듯합니다.
저두 금융권에서 유닉스에 C로 코딩하고 있습니다. 2개의 프로젝트를
진행했는데, 첫번째 프로젝트는 담당자가 유닉스를 전혀 몰라서 프로그램
네이밍에 대해서 전혀 터치를 안하더군요.
두번째는 imgromit 님이 예시한것 같은 룰을 적용하도록 강요 받았습니다.
물론 그 규칙은 프로그램 이름과 함수 이름에도 적용하도록 강요하더군요.
연유를 물어보니 우리나라 S** 회사가 컨설팅을 하면서 그렇게 룰을
정했다고 하더군요.
아마 룰이 맘에 안드시더라도 참고 적응을 하셔야 할 듯 합니다.
이 룰이 적용되면 문제가 함수 이름이나 프로그램 이름을 보고 실제
기능하고 매치가 전혀 안됩니다. 하다보면 이름을 외우게 되고 그냥
이름을 들으면 이게 뭐다 알게 되지만, 나중에 인수받는 담당자들은
엑셀파일에 적어달라고 해서 그걸로 하나하나 비교하면서 필요한
프로그램을 찾는것 같더군요. :roll:
저는 이런 방식의 명명법을 처음 봅니다.헝가리언 표기법의 개념을 함수
저는 이런 방식의 명명법을 처음 봅니다.
헝가리언 표기법의 개념을 함수 이름에도 적용한 것이군요.
프로그램이 변경될 때마다 이름과 실제를 맞춰줘야 하는 부담이 있는 것이
헝가리언 표기법의 큰 단점이죠.
IBM 중대형 시스템의 프로그램들에서 흔히 보는 명명 관례입니다. 아직도
IBM 중대형 시스템의 프로그램들에서 흔히 보는 명명 관례입니다. 아직도 제약 사항이 풀린 것도 있고 아닌 것도 있는 시스템들이 있지만, 10자리로 프로그램 이름이나 함수명을 적어야 했을 때는 두자리 시스템 이름, 메뉴를 알기위한 세 네자리 숫자 + 플러스 알파 등으로 이름을 작명하곤 했습니다.
그걸 한 번에 변경하지 못하고, 유지해서 그나마 _라도 붙여 저렇게 쓰는 걸 겁니다.
----
I paint objects as I think them, not as I see them.
atie's minipage
[quote="imgromit"]함수의 depth 는 제가 표현을 잘 못
호출간의 연관성을 작명시에 의미적으로 표현하겠다는 것은 좋은 생각(?)같습니다. 만드는 측면에서는 번거롭겠지만, 그것을 보고 이해하는 측면(함수의 호출관계를 함수명으로 판단할 수 있다는)에서는 좋아보입니다(개인적으로 사용하고 싶지 않지만).
개인적으로 C언어가 갖는 단점중 하나가 name space 가 하나라는 사실입니다. 즉, 명칭이 겹칠수 있기에 많은 개발자들이 동시에 프로젝트를 진행하는 경우는 유일하게(?) 작명하는 방법 또는 그것에 준하는 프래임웍크이 필요할 것입니다.
아마도 이런 취지에서 작명이 시작되야 하며 추가적으로 업무의 성격도 같이 포함해서 할것인지를 결정하면 될 것 같습니다.
그 이전에 파일명의 작명법도 같이 생각해 두는 것이 좋겠습니다.
금융권의 업무는 단위별 분류가 명확할 것 같습니다. 만약 그렇다면, 업무의 성격이 약어집에 있을것이고 이를 기반으로 조합하는 작명규칙을 만드는것은 어쩌면 개발자들에게도 편리성을 줄것이라 생각합니다. 필요한 교육이 선행되어야 한다는 조건이 있습니다.
개발자들의 생각과 능력이 공유된다면 작명법들은 필요치 않을 것입니다. 하지만, 그럴 가능성이 없기에 누군가는 그런 업무를 정의하고 관리해 줘야 할 것입니다.
함수 명명의 대부분은 분석과 설계에 기인하기 때문에 그 부분이 명확하면 명확할 수록 명칭들은 명확히 결정됩니다.
댓글 달기