Wed Oct 17 - Avoiding Code Smells by Walter Bright

[H. S. Teoh]

On Thu, Nov 01, 2018 at 10:37:59PM +0000, unprotected-entity via Digitalmars-d-announce wrote:
> On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
> > 
> > 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.
> 
> How does one determine, whether a 10,000 line module, is tightly
> coupled and cohesive?
> 
> Only the author can make that statement - which they naturally will,
> even if it's not true.
> 
> An outsider, seeking to verify that statement, has a hell of a job on
> their hands...(I for one, think code smell immediately).

The code reviewer can reject a 10,000-line module off the bat as being
too large.  It's up to the project to enforce such conventions.


> As soon as you see a class interface in a module, in D, you have to
> assume their is other code in the module, perhaps down around line
> 9,900, that is bypassing its interface, and doing who knows what to
> it....
> 
> Sure, the author might be happy, but an auditor/code reviewer, will
> likely have a different view, when a 10,000 line module is shoved in
> front of them, and they know, that 'anything goes', 'all bets are
> off', inside the D module....

Yes, and this is when you, or the project manager, puts down the foot
and say this is unacceptable, break this module up into smaller
submodules or else it doesn't go into the master repository.  Simple.


[...]
> I don't use a particular language. I'm more interested in design and
> architecture.
> 
> In the age of 'lock-down-everything', increased modularity is becoming
> more important. A monolithic module approach, is already outdated, and
> risky, in terms of developing secure, maintainable software....

I don't understand what D's approach to modules has to do with being
monolithic.  Why can't you just write smaller modules if private being
module-wide bothers you so much?  D has package.d that can make a set of
smaller submodules appear as a larger module to outside code.  Use it.


> I think providing an additional tool, to those who seek to use D, such
> as 'strict private' (syntax can be argued about), would aid better
> design - it can't make it any worse, that's for sure).
> 
> Although. I don't mean strict private like freepascal, but strict
> private, as in it inherits everything that private already does, but
> additionally, become private within the module too.
> 
> Is that really such a bad idea? Are there no programmers out there in
> the D world that might think this could be a good, additional tool, to
> give programmers, so they can better architect their solution?

It's not a bad idea. In fact, if I were in charge of designing D, I'd
probably do the same.  But D chose to do it differently -- and part of
the rationale, if I understand it correctly, is to eliminate the need
for `friend` declarations like in C++.  But maybe Andrei or whoever it
was that made this decision can step up and explain why it was designed
this way.

All we're saying is that it's not the end of the world if private is
module-wide rather than aggregate-wide.  You can still have your
encapsulation by splitting up your code into smaller files, which, given
what you said above, you want to be doing anyway since the idea of a
10,000-line source file is so abhorrent to you.

The fundamental issue here is that there needs to be some kind of unit
of encapsulation.  Java and C# chose to make the class that unit; D
chose the module.  If the Java/C# unit of encapsulation is what you
want, all you have to do is to make the module equivalent to the class,
problem solved.  It's not as though there is no encapsulation at all and
you're left out in the wild west of C's global namespace, or that the
workaround is too onerous to be practical.


> The amount of push back in the D community on this idea, is really odd
> to me. I'm still trying to understand why that is. Are D programmers
> just hackers, insterested in getting their code to work, no matter
> what? Are their not enough Java/C# programmers coming to D - and
> bringing their design skills with them?

It's not so much push back, as being worn out from every other newcomer
clamoring for the same thing year after year without ever having tried
to do it the D way.  Not saying that you're doing that, but it just
becomes a sort of knee-jerk reaction after X number of newcomers barge
in repeating the same old complaints that has the same old answers that
everyone is tired of repeating.

Having said that, though, there are some here who *do* want something
like what you describe... IIRC Manu has voiced this before, and there
may be others. (I myself don't consider it a big enough issue to be
worth agonizing over.)  So far, there has yet to be a strong enough
argument for per-aggregate private to convince Walter & Andrei.  It's
them you have to convince, not the rest of us.  Even if we were to all
agree with you, it doesn't mean squat if Walter and Andrei won't budge
on the issue.

And they are unlikely to budge as long as (1) there is a perfectly
workable solution to the problem -- in this case, split up your code
into submodules, and use package.d to group them into a logical parent
module if you wish; and (2) the proposed language addition/change brings
strong enough benefits to offset the technical debt of yet another
complication added to the language.

(Personally, I think they're a bit too conservative on changes that
would ostensibly improve the language. But again, what I think means
squat -- they are the decision-makers, not me.)


T

-- 
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert