Here (pdf alert) I have found a very simple but interesting paper that has confirmed an hypothesis of mine.

This is a page that contains a pdf that shows a short introduction to the paper: http://www.ganssle.com/tem/tem80.htm

This is the paper, "Using Redundancies to Find Errors", by Yichen Xie and Dawson Engler, 2002: www.stanford.edu/~engler/p401-xie.pdf


A trimmed down quote from the tem80 page:

>Researchers at Stanford have just released a paper detailing their use of automated tools
to look for redundant code in 1.6 million lines of Linux. "Redundant" is defined as:
- Idempotent operations (like assigning a variable to itself)
- Values assigned to variables that are not subsequently used
- Dead code
- Redundant conditionals

They found that redundancies, even when harmless, strongly correlate with bugs. Even when the extra code causes no problems, odds are high that other, real, errors will be found within a few lines of the redundant operations.

Block-copied code is often suspect, as the developer neglects to change things needed for
the code’s new use. Another common problem area: error handlers, which are tough to
test, and are, in data I’ve gathered, a huge source of problems in deployed systems.
The authors note that their use of lint has long produced warnings about unused variables
and return codes, which they've always treated as harmless stylistic issues. Now it's clear
that lint is indeed signalling something that may be critically important.
The study makes me wonder if compilers that optimize out dead code to reduce memory
needs aren't in fact doing us a disservice. Perhaps they should error and exit instead.<


This study confirms that situations like:
x = x;
often hide bugs, unused variables are often enough (as I have suspected, despite what Walter said about it) a sign for possible real bugs, and assigned but later unused variables too may hide bugs.

This paper has confirmed that some of my enhancement requests need more attention:

http://d.puremagic.com/issues/show_bug.cgi?id=3878 http://d.puremagic.com/issues/show_bug.cgi?id=3960 http://d.puremagic.com/issues/show_bug.cgi?id=4407


situations like x=x; reveal true bugs like:

class Foo {
    int x, y;
    this(int x_, int y_) {
        this.x = x;
        y = y;

    }
}
void main() {}


Now I think that such redundancies and similar things often enough hide true bugs. But what to do? To turn x=x; into a true error? In a comment to bug 3878 Don gives a situation where DMD may raise a true true compile-time error. But in other cases a true error looks too much to me.

Bye,
bearophile

bearophile Wrote:

> errors will be found
> often hide bugs

> situations like x=x; reveal true bugs like:
> 
> class Foo {
>     int x, y;
>     this(int x_, int y_) {
>         this.x = x;
>         y = y;
> 
>     }
> }
> void main() {}

Yes, fields and locals in camelCase is a bug.

On Thursday 30 September 2010 23:33:26 Kagamin wrote:
> bearophile Wrote:
> > errors will be found
> > often hide bugs
> > 
> > situations like x=x; reveal true bugs like:
> > 
> > class Foo {
> > 
> >     int x, y;
> >     this(int x_, int y_) {
> > 
> >         this.x = x;
> >         y = y;
> > 
> >     }
> > 
> > }
> > void main() {}
> 
> Yes, fields and locals in camelCase is a bug.

??? Why on earth would it be a bug to have variable names in camelcase? Camelcase is purely a stylistic issue - and one which most people adhere to.

- Jonathan M Davis

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:i83cil$2o02$1@digitalmars.com...
>
> situations like x=x; reveal true bugs like:
>
> class Foo {
>    int x, y;
>    this(int x_, int y_) {
>        this.x = x;
>        y = y;
>
>    }
> }

I get hit much more often by somthing like this....

class Foo {
   int m_x, m_y;
   this(int x, int y)
   {
       int m_x = x;
       int m_y = y;
   }
}

I dont know if it is, but IMO it really should be an error to declare local variables that hide member variables.

> I dont know if it is, but IMO it really should be an error to declare local variables that hide member variables.

I disagree. I always do that in constructors:

int x, y;
this(int x, int y)
{
  this.x = x;
  this.y = y;
}

I think you would annoy a lot of people if it was forbidden.

On Fri, Oct 1, 2010 at 9:50 AM, Peter Alexander <peter.alexander.au@gmail.com> wrote:
>> I dont know if it is, but IMO it really should be an error to declare local variables that hide member variables.
>
> I disagree. I always do that in constructors:
>
> int x, y;
> this(int x, int y)
> {
>  this.x = x;
>  this.y = y;
> }
>
> I think you would annoy a lot of people if it was forbidden.
>

I do the same, but got a nasty bug that took me hours to find because in one condition later down the constructor I forgot the "this." prefix. this kind of bug is hard to spot by just reading the code.

IMHO it's quite tedious to do all these  assignments in a constructor anyway - it'd be cool to have some possibility to say "this constructor argument should be assigned to the classes field of the same name", like

int x, y, z;

this(class int x, class int y, int a) {
  // this.x and this.y are set implicitly
  this.z = (x+y)/a;
}

or something like that. Dunno if "class" is an appropriate keyword for
that (probably not), but it should suffice to illustrate the idea.
Well, maybe "this(int this.x, int this.y, int a)" would be better.
And maybe this wouldn't need addition to the language at all but could
be done with some template/string-mixin magic.
I haven't really thought this through, but *some* possibility to do
this (assign constructor- or even function-arguments to class field of
same name) would be cool :-)

Daniel Gibson <metalcaedes@gmail.com> wrote:

> this(int this.x, int this.y, int a)

Me likes.

-- 
Simen

"Peter Alexander" <peter.alexander.au@gmail.com> wrote in message news:i843rl$1gr9$1@digitalmars.com...
>> I dont know if it is, but IMO it really should be an error to declare
>> local
>> variables that hide member variables.
>
> I disagree. I always do that in constructors:
>
> int x, y;
> this(int x, int y)
> {
>  this.x = x;
>  this.y = y;
> }
>
> I think you would annoy a lot of people if it was forbidden.

I'm sure it would. But i think the benefit would outweigh the cost. I mean the cost is coding style, personal preference, the benefit is fewer bugs.

And people would get used to it.

On 1/10/2010 11:12 AM, bearophile wrote:
> Here (pdf alert) I have found a very simple but interesting paper that has confirmed an hypothesis of mine.

So far most respondents have gone completely off-subject here.

In hardware systems redundancy is critical for safety.  In software
systems redundancy is bad because, as you and the paper suggest,
redundancy makes for bugs.  The principle for software is both
normalization, DRY (do not repeat yourself) and ZIP (zero intolerance
for plagiarism).

As always, I enjoy your interesting posts.

Regards
Justin Johansson

On 2/10/2010 1:52 AM, Justin Johansson wrote:
Whoops, bug in my reply.
ZIP as "zero intolerance for plagiarism" is obviously
what I did not mean.  I meant "zero tolerance"
rather than "zero intolerance" but then the acronym
ZTP does not sound so good, :-(