Wed Oct 17 - Avoiding Code Smells by Walter Bright

[H. S. Teoh]

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