> but my point is that code absolutely can and should clearly reflect many of the things you would also cover in documentation. I absolutely agree, but my poi

> but my point is that code absolutely can and should clearly reflect many of the things you would also cover in documentation. I absolutely agree, but my point was very specific about the "what should" and "why". At best, one could infer some intent from invariants, and hopefully the mapping between the invariants and the requirements document is pretty clear, but comments are still better at explicitly referencing requirements documentation and explaining why the chosen solution is preferable to alternatives.