On Thu, Nov 01, 2018 at 02:45:19AM +0000, unprotected-entity via Digitalmars-d-announce wrote: [...] > Another thing to look for, is signs of code smell. I would include in > this, unit tests calling private methods (which seems to be a popular > thing for D programmers to do). Some will disagree that this is a code > smell, but I have yet to see a good argument for why it is not.
White-box testing. In principle, I agree with you that if your unittests are doing black-box testing, then they should definitely not be calling private methods. However, limiting yourself to black-box testing means your private functions can be arbitrarily complex and yet it's not thoroughly tested. Sometimes you really do want a unittest to ensure the private method is doing what you think it's doing, and this requires white-box testing. This is especially important to prevent regressions, even if it seems redundant at first. Only doing black-box testing means a later code change in the private method can subtly introduce a bug that's not caught by the unittest (because it cannot call a private method directly to verify this). > Forget LOC. Look for good architecture, decoupling, modularity, > encapsulation, information hiding....etc..etc... again, sadly, these > concepts are not directly promoted when writing modules in D, since > the module exposes everything to everything else in the module - and > programmers will surely make use of any convenient hack that avoids > them having to think about good architecture ;-) [...] Actually, code within a module *should* be tightly coupled and cohesive -- that's the whole reason to put that code inside a single module in the first place. If two pieces of code inside a module are only weakly coupled or completely decoupled, that's a sign that they should not be in the same module at all. Or at the very least, they should belong in separate submodules that are isolated from each other. But besides all this, D's philosophy is about mechanism rather than policy. The goal is to give the programmer the tools to do what he needs to do, rather than a bunch of red tape to dictate what he cannot do. That's why we have @trusted, @system, and even asm. The programmer is responsible for making sane architectural decisions with the tools he is given, rather than being told what (not) to do within the confines of his cell. If you're looking for policy, maybe Java would suit you better. :-P T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
