• Mike Parker (7/7) Jun 02 2018 In this post for the D Blog, Jack Stouffer details how dscanner
• Microbe (12/19) Jun 02 2018 As you know, surrounding code within a module can infilitrate the
• Basile B. (3/14) Jun 02 2018 Microbe, if you were a keyword for a protection attribute in a
• Microbe (14/16) Jun 02 2018 To borrow a quote from someone else on this forum.. knock of the
• Jon Degenhardt (6/13) Jun 02 2018 Nice post. I haven't tried dscanner on my code, but I plan to
• Steven Schveighoffer (20/30) Jun 04 2018 I like the article, but was taken aback a bit by this quote: "for
• Joakim (3/9) Jun 04 2018 I think he was talking about _unrelated_ doc changes.
• Steven Schveighoffer (7/18) Jun 04 2018 Well, how unrelated? If, for instance, you are changing the docs to
• drug (3/23) Jun 05 2018 But what if your commit with this typo would be reverted? Then you lost
• Steven Schveighoffer (4/28) Jun 05 2018 Then you fix the typo again? Reverts don't happen enough to justify this...
• Steven Schveighoffer (6/34) Jun 05 2018 To clarify a bit, complicated or controversial changes that are likely
• drug (4/11) Jun 05 2018 Adding fixes for docs is fine for me too. I just don't like mixing

Mike Parker <aldacron gmail.com> writes:

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/

Microbe <mic mic.com> writes:

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?

Basile B. <b2.temp gmx.com> writes:

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

Microbe <mc mc.com> writes:

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.

Jon Degenhardt <jond noreply.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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_continuo
s_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

Joakim <dlang joakim.fea.st> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

drug <drug2004 bk.ru> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 6/5/18 9:58 AM, Steven Schveighoffer wrote:
 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.

To clarify a bit, complicated or controversial changes that are likely 
to be delayed or stalled, should be split from simple doc changes if it 
turns out it's not going to be pulled anytime soon. But normally, adding 
fixes for docs I would think is fine.

-Steve

drug <drug2004 bk.ru> writes:

05.06.2018 17:00, Steven Schveighoffer пишет:
 
 To clarify a bit, complicated or controversial changes that are likely 
 to be delayed or stalled, should be split from simple doc changes if it 
 turns out it's not going to be pulled anytime soon. But normally, adding 
 fixes for docs I would think is fine.
 
 -Steve

Adding fixes for docs is fine for me too. I just don't like mixing 
unrelated changes in a commit. But nevertheless I did it. The world 
isn't ideal)