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