Wed Oct 17 - Avoiding Code Smells by Walter Bright

[unprotected-entity]

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).

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....

> 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

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 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?

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?