> That doesn't mean there's a problem with the code, only with the documentation.<p>I disagree. If the obvious way to use an API is the incorrect way, there is a problem with the code.<p>If you must call A each time before calling B, drop A and have B do both things.<p>If you must call A once before calling B, make A return a token that you then must pass to B to show you called A.<p>As another example, look at <a href="https://blog.trailofbits.com/2026/02/18/carelessness-versus-craftsmanship-in-cryptography/" rel="nofollow">https://blog.trailofbits.com/2026/02/18/carelessness-versus-...</a> (HN discussion: <a href="https://news.ycombinator.com/item?id=47060334">https://news.ycombinator.com/item?id=47060334</a>):<p><i>“Two popular AES libraries, aes-js and pyaes, “helpfully” provide a default IV in their AES-CTR API, leading to a large number of key/IV reuse bugs. These bugs potentially affect thousands of downstream projects.”</i><p>Would you call that “poor code style that could theoretically lead to a bug in the future”, too?