c++ - Dual purpose code commenting(users & maintainers)...HOW? -


i writing c++ static library , have been commenting doxygen comments in implementation files. have never had care documentation working on needs documented users , trying replace previous bad habit of wanting code , not document better software engineering practices.

anyway, realized other day need couple different types of documentation, 1 type users of library(doxygen manual) , comments myself or future maintainer deal more implementation details.

one of solutions put doxygen comments file, class, , methods @ bottom of implementation file. there out of way , include normal comments in/around method definitions benefit programmer. know it's more work seems best way me achieve 2 separate types of commenting/documentation. agree or have solutions/principles might helpful. looked around site couldn't find threads dealt this.

also, don't want litter interface file comments because feel it's better let interface speak itself. rather manual place user can if need deeper understanding of library interface. on right track here?

any thoughts or comments appreciated.

edit: comments. have learned alot hearing them. think have better uderstanding of how go separating user manual code comments useful maintainer. idea @jalf has having "prose" style manual helps explain how use library. think better reference manual. being said...i feel reference manual might come in handy. think combine advice thoughts of others , try create hybrid.(a prose manual(using doxygen tags page, section, subsection) links reference manual.) suggestion liked @jalf idea of code not having whole manual interleaved it. can avoid placing of doxygen comments @ bottom of implementation file. leaves headers clean , implementation clean place comments useful maintaining implementation. see if works out in reality. these thoughts on have learned far. not positive approach going work or practical. time tell.

i believe comments users should not inline in code, doxygen comments or that. should separate document, in prose form. user of library, don't need to, or want to, know each parameter function means. hopefully, that's obvious. need know function does. , need know why , when call it. , need know pre- , postconditions apply. assumptions function make when call it, , guarantees provide when returns?

library users don't need comments, need documentation. describe how library structured , how works , how use it, , outside code, in actual text document.

of course, code may still contain comments directed @ maintainers, explaining why implementation looks way does, or how works if it's not obvious. documentation library user needs should not in code.


Comments

Popular posts from this blog

c++ - Convert big endian to little endian when reading from a binary file -

gdi+ - WxWidgets draw a bitmap with opacity -

C#: Application without a window or taskbar item (background app) that can still use Console.WriteLine() -