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.

Reply via email to