markany-linux / openCode

개방형 OS 공용 라이브러리 개발
GNU General Public License v3.0
10 stars 2 forks source link

lib_utility의 인터페이스 함수들에 관하여 #1

Open qoor opened 4 years ago

qoor commented 4 years ago

lib_utility가 각종 편의성을 위한 API를 제공해주는 동적 라이브러리인 것 같습니다.

내부 코딩 가이드라인에 따라서 extern 함수들과 라이브러리 내부에서 돌아가는 실제 함수들이 구분돼있는 것 같습니다.

물론 내부 함수 네이밍 규칙이 snake_case이고, extern 함수들의 네이밍 규칙은 Camel Case로 나뉘어져 있지만, 이 라이브러리 규모가 커질 경우 코드 가독성이 저하되지 않을까 하고 조심스럽게 의견을 내어봅니다.

제가 생각하는 솔루션은 두 가지입니다.

  1. API들은 따로 인터페이스 정의 파일을 만들어서 분리(ex: string_parser_interface.c)
  2. API와 내부 함수의 동작이 대부분 같으므로 어차피 노출해야 할 기능의 함수라면 과감하게 한 함수로 통합하고 노출 (내부용 get_target_string_ptr, 외부용 getTargetStringPtr이 같은 동작을 하므로, get_target_string_ptr의 내용을 getTargetStringPtr에 통합)
unangel commented 4 years ago

안녕하세요. 의견 감사합니다.

lib_utility 라이브러리 용도는 확인하신 내용과 동일한 목적을 가지며, 말씀 주신것과 같이 라이브러리 규모가 커질 것에 대비하여, 함수 이름 규칙을 정한 것입니다. C에서 C++의 namespace를 사용할 수 없기 때문에 이러한 효과를 만들기 위한 하나의 방법으로 보시면 되겠습니다.

코드 가독성의 경우, 현재 파일 별로 구성되어 있는데 어떤 가독성을 말씀하시는 것인지 궁금합니다. 그리고, 본 프로젝트의 경우 Doxygen 형식의 주석을 채택하여 필요한 모든 부분에 주석을 입력하고 있습니다. 따라서 인터페이스 헤더 파일(utility_interface.h)의 참조만으로 외부에서는 아래와 같이 정보를 확인할 수 있습니다.

image

따라서 어떤 가독성에 대해서 말씀하신 것인지 정확히 말씀해 주시면 좋겠네요. 마지막으로 의견주신 솔루션 1의 경우에는 인터페이스 정의 파일(.h)를 말씀하신 것이겠지요?? 이는 위 그림과 같이 인터페이스 정보를 제공하는 것으로 해결이 될 것 같습니다.

솔루션 2의 경우는 내부적으로도 고민입니다만, 본 프로젝트처럼 단일 라이브러리의 경우라면 적용할 수 있을 것 같습니다.