www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Driving Continuous Improvement in D

reply 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/
Jun 02
next sibling parent reply 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?
Jun 02
parent reply 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".
Jun 02
parent 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.
Jun 02
prev sibling next sibling parent 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.
Jun 02
prev sibling parent reply 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
Jun 04
parent reply 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.
Jun 04
parent reply 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
Jun 04
parent reply 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.
Jun 05
parent reply 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
Jun 05
parent reply 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
Jun 05
parent 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)
Jun 05