Testing and documentation of internal functions

[kroeker@…]

Hello,

I suggest that not only the public functions of a library (or a package) should be reasonanle tested and documented, but also the internal ones. The documentation standard for internal code could be alleviated, but in general in my opinion it is unfortunate that internal functions are not documented or not tested, because since the academic environment has high personnel fluctuation, undocumented and untested code will significantly handicape the maintenance or code reusage and in the long run reduce the development productivity and project quality.

If someone has a different opinion, please argue.

Jakob

Remark: introducing code review processes may also have positive influence on code quality and thus in the long term on productivity.

[Oleksandr]

Do you mean static procedures in official Singular libs?

[hannes]

Tests and documention for all source code is already required. Formalizing the tests for internal routines will not be done: they are - as the name says - internal and shall not test for dumb user input. Tests for internal routines requires a certain environment which should go to the test files (Test files can include the examples but should not be limited to them: examples are educational: should show the typical use while test files should (also) test corner cases.

PS: this is a bug tracker, not a dicussion forum.