Wed Oct 17 - Avoiding Code Smells by Walter Bright

[Neia Neutuladh]

On Thu, 01 Nov 2018 22:37:59 +0000, unprotected-entity 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?

You can get a pretty accurate result by just saying "no". 10KLOC in one 
module is almost always a problem.

Failing that, you can do a code review. Which will take a very long time. 
The solution to that is to submit less code at a time, review as you go, 
and keep modules smaller.

For instance, Phobos keeps most modules below 3000 lines of code, 
including unittests. The largest module, std.datetime.systime, has about 
6000 lines of code -- but if you exclude unittests and test-only code, it's 
more like 1000.

> Only the author can make that statement - which they naturally will,
> even if it's not true.

I think a lot of programmers are well aware of the failings of their code.

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

And so you have a rule against casting from an interface to a concrete 
type, if that's a thing that worries you. It's something you can check 
rather easily in a reasonably sized code review.

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

That statement could be taken as being against an approach that recommends 
structuring a project as a monolithic module, or against an approach that 
treats modules as a monolith in terms of protection.

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

It would be more language complexity in order to make it easier to have 
large modules. But you already said that large modules are a problem.

> 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 use case is when you don't want to break up a module and you don't 
trust yourself not to modify private members from the wrong parts of the 
module.

That's not useless.

It's also not obviously so useful as to merit inclusion. A lot of languages 
do without any notion of private. A lot, like the entire ALGOL family up 
to Oberon-2, Go, Rust, Lua, Haskell, and Node.js, use exported and 
unexported symbols instead, and that's per module. A fair number just don't 
have a notion of public and private symbols.

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

There are plenty of language designers that didn't think it obvious. Might 
be better to consider why instead of implying that no D programmers are 
familiar with or care about good design. I mean, if there are popular 
languages from the 1960s through the 2010s that do things the same way as 
D, that sounds like a pretty good indication that it's not an obviously bad 
idea. It's not rock-solid; actual evidence from the industry would be 
superior. But I think you would have presented that evidence already.