On 07/20/2016 06:33 PM, Lukas Slebodnik wrote:
On (20/07/16 18:05), Nikolai Kondrashov wrote:
> On 07/20/2016 05:28 PM, Lukas Slebodnik wrote:
>> c) if it is a hard to write unit test than it means that functions is
>> complicated or do a lot of things and should be refactored. => refactored
code
>> will be easier to read, to understand and to test.
>
> BTW, same goes with documentation :)
> If it's hard to write, then code needs refactoring.
>
No,
because you can write documentation even for function which is hard to unit
test. Documentation might help to increase understanding of code.
But it does not enforce better code.
Sure, although strictly speaking unit tests don't absolutely enforce better
code either. They're just harder to write in general, and so provide more
incentive to refactor the code, but you can still write a unit test even for a
bad code, although the test itself will be more complex and will test less.
There is no limit to amount of code a non-lazy programmer can write ;)
I.e., yes, unit tests enforce better code stronger than documentation.
However, my response was just an observation of minor benefit of
documentation, not the main reason why we should do it.
> Oh, and documentation is easier to write than unit tests, we can
never write
> unit tests for everything.
>
"easier to write" does not mean better/more readable code.
Unit test is much stricter than documentation.
BTW It does not mean that we should not use documentation comments.
We can describe "test-case" in unit test so it will be easier to
find out which use case do you want to cover with the test.
Sometimes it can be find out from the name of test.
IMHO, we should use some mixed way.
We can have a documentation for stable parts of code (e.g. sysdb)
and unit tests for other parts of code.
I fully agree that unit tests help improve code and fully support adding more
of them, especially if they're well commented. However, the effect they have
on making the code easier to understand is lower and it's harder to achieve.
Because they're still *code*, not natural language, they don't describe the
code *directly*, and they're harder to write than documentation.
In short, if I was told: "if you want to understand this code, go and read
some more of other code (tests)" or "here is how this works", I would
choose
the latter.
Regarding documenting only stable code there are several problems. First, how
and when to define code as "stable". Then, we don't need contributions to
stable code as much as to unstable. I.e. we rarely need fixes to such code, and
generally will be wary of new features there.
Nick