In this post for the D Blog, Jack Stouffer details how dscanner is used in the Phobos development process to help improve code quality and fight entropy.

The blog:
https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/

reddit:
https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/

On Saturday, 2 June 2018 at 07:23:42 UTC, Mike Parker wrote:
> In this post for the D Blog, Jack Stouffer details how dscanner is used in the Phobos development process to help improve code quality and fight entropy.
>
> The blog:
> https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/
>
> reddit:
> https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/

As you know, surrounding code within a module can infilitrate the membrane structure of those types that use 'private' to protect their boundary (for example, the 'private' member in that struct, in that blog).

Since the compiler is completely useless in such situations (as it conspires with the surrounding code 'to ensure that it can infiltrate your types'), what does dscanner bring to the table, if anything, to help the programmer to ensure such types don't die a quick death due to the cytotoxic effect the module has on such types?

Or is this not considered a 'quality' issue in D?

On Saturday, 2 June 2018 at 12:49:45 UTC, Microbe wrote:
> As you know, surrounding code within a module can infilitrate the membrane structure of those types that use 'private' to protect their boundary (for example, the 'private' member in that struct, in that blog).
>
> Since the compiler is completely useless in such situations (as it conspires with the surrounding code 'to ensure that it can infiltrate your types'), what does dscanner bring to the table, if anything, to help the programmer to ensure such types don't die a quick death due to the cytotoxic effect the module has on such types?
>
> Or is this not considered a 'quality' issue in D?

Microbe, if you were a keyword for a protection attribute in a programming language, i would choose "smuck".

On Saturday, 2 June 2018 at 13:32:00 UTC, Basile B. wrote:
>
> Microbe, if you were a keyword for a protection attribute in a programming language, i would choose "smuck".

To borrow a quote from someone else on this forum.. knock of the sex talk!.

Anyway, increased membrane permeability leads to rupture, followed by death.

Why should I exposed my objects to the toxic effects of the D module?

And if encapsulation is not a 'quality' issue, then I don't know what is.

In biology, encapsulation is the basis for life - it's why you and I exist.

So my question is valid (even if you don't like it).

Since the compiler won't protect my objects from the toxic effects of the D module, I am curious how dscanner can help.

On Saturday, 2 June 2018 at 07:23:42 UTC, Mike Parker wrote:
> In this post for the D Blog, Jack Stouffer details how dscanner is used in the Phobos development process to help improve code quality and fight entropy.
>
> The blog:
> https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/
>
> reddit:
> https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/

Nice post. I haven't tried dscanner on my code, but I plan to now. It looks like the documentation on the dscanner repo is pretty good. If you think it's ready for wider adoption, consider adding a couple lines to the blog post indicating that folks who want to try it will find instructions in the repo.

On 6/2/18 3:23 AM, Mike Parker wrote:
> In this post for the D Blog, Jack Stouffer details how dscanner is used in the Phobos development process to help improve code quality and fight entropy.
> 
> The blog:
> https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/
> 
> reddit:
> https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/ 
> 

I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function."

Really? I both was not aware of this policy, and don't understand why you wouldn't fix the docs at the same time. Can you elaborate?

I'll give you an example of what I was thinking of. Let's say you have a function foo:

/**
 * foo takes a parameter and returns true if ...
 */
bool foo(T)(T t) { ... }

And you realize foo really should only take integer parameters:

/**
 * foo takes integer parameters and returns true if ...
 */
bool foo(T)(T t) if (isIntegral!T) { ... }

Why not both edit the function and fix the docs in the same PR? In fact, why would we *accept* the change without updating the docs?

-Steve

On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote:
> On 6/2/18 3:23 AM, Mike Parker wrote:
>> [...]
>
> I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function."
>
> [...]

I think he was talking about _unrelated_ doc changes.

On 6/4/18 1:51 PM, Joakim wrote:
> On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote:
>> On 6/2/18 3:23 AM, Mike Parker wrote:
>>> [...]
>>
>> I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function."
>>
>> [...]
> 
> I think he was talking about _unrelated_ doc changes.

Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case.

-Steve

04.06.2018 21:08, Steven Schveighoffer пишет:
> On 6/4/18 1:51 PM, Joakim wrote:
>> On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote:
>>> On 6/2/18 3:23 AM, Mike Parker wrote:
>>>> [...]
>>>
>>> I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function."
>>>
>>> [...]
>>
>> I think he was talking about _unrelated_ doc changes.
> 
> Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case.
> 
> -Steve

But what if your commit with this typo would be reverted? Then you lost your typo fix too.

On 6/5/18 3:20 AM, drug wrote:
> 04.06.2018 21:08, Steven Schveighoffer пишет:
>> On 6/4/18 1:51 PM, Joakim wrote:
>>> On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote:
>>>> On 6/2/18 3:23 AM, Mike Parker wrote:
>>>>> [...]
>>>>
>>>> I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function."
>>>>
>>>> [...]
>>>
>>> I think he was talking about _unrelated_ doc changes.
>>
>> Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case.
>>
> 
> But what if your commit with this typo would be reverted? Then you lost your typo fix too.

Then you fix the typo again? Reverts don't happen enough to justify this concern.

-Steve