Missing compiler warning?

Chris wendlec at tcd.ie
Mon Oct 21 02:24:06 PDT 2013


On Monday, 21 October 2013 at 09:05:58 UTC, Jonathan M Davis 
wrote:
> On Monday, October 21, 2013 10:37:57 Chris wrote:
>> Usually same-name
>> variables are only used in the constructor. Using them in other
>> places in the class is not recommendable
>
> Well, that's up to the programmer, and plenty of folks use them 
> in places like
> setters as well.
>
>> but is it a good solution to categorically rule out warnings?
>
> Honestly? Yes, I think that it is. I am of the opinion that the 
> _only_
> warnings that the compiler should have are things that will 
> become errors
> later but aren't immediately in order to give programmers the 
> chance to change
> their code before it breaks. For instance, override is now 
> required on virtual
> functions which override a base class function, whereas before 
> it wasn't - we
> used a warning to ease the transition, and that makes sense. 
> But ultimately,
> it became an error.
>
> Because it is not good practice to ever leave warnings in your 
> code, I am
> firmly of the belief that something should be an error or 
> completely legal and
> nothing in between. Otherwise, you're needlessly forced to 
> change your code
> just because it _might_ have a problem.
>
> Additional lint-like tools can be written and used to check for 
> anything which
> "might" be wrong, and the compiler can be left to report only 
> stuff that is
> definitively wrong. And once we have a D lexer and parser in 
> Phobos (and we're
> getting close to having a lexer), writing such tools will 
> become much easier,


> and then such tools can warn programmers about what _they_ want 
> to be warned
> about but which isn't necessarily wrong.
>
> - Jonathan M Davisbut is

That would be a good solution, so ideally programmers could have 
a list of "bad practice" and check against that too.

I only wonder which other use cases there are for same name 
variables other than constructors and setters.

void setValue(string input) {
   this.input = input;
}

But there you have this. But a function (in the same class) like

void processInput() {
   auto input = // ...
   // 20 lines later
   input = std.string.format("Hello %s!", someString);
}

Why would one want to write code like this? Why should a 
short-lived local variable assume the name of a class variable? 
This is a source of confusion and I don't consider this good 
practice. Maybe it's just personal taste.


More information about the Digitalmars-d mailing list