Repository navigation
Suggestion: disallow use before initialization #2234
Description
TypeScript 1.4 allows variables to be used before they are initialized.
For example, both:
function dd(): number {
var x: number;
return x;
}and
function ddd() {
var x: number;
x++;
}are allowed.
It would be useful to have a compiler flag such as --noUseBeforeInit that would turn variable use before initialization into an error.
This suggestion fits in with #274 meta-bug.
Activity
danquirk commentedon Mar 10, 2015
I think we have a bug on this already but I'm having trouble finding it. It's one part of #2176
neilgalarneau commentedon Mar 11, 2015
Mohamed Hegazy (@mhegazy) Duplicate of what?
#2176 doesn't mention "Use before Initialization".
mhegazy commentedon Mar 11, 2015
sorry about that. fixing labels.
drakarah commentedon Aug 29, 2015
+1, I'd like to see this as well.I didn't know I was so reliant on the C# compiler warning me that I was using fields that weren't initialized until I started using typescript. Array fields in particular are a weak point for me. I keep writing 'private arr:number[];' and forgetting the '= []; ' part afterwards.
kitsonk commentedon Aug 30, 2015
Traditionally in JavaScript this had been the land of the linting too, because it is "valid" and there maybe use cases where it is "valid". Wouldn't palantir/tslint be a better place for this if it isn't already there?
ping Adi Dahiya (@adidahiya)
drakarah commentedon Aug 30, 2015
I wouldn't let the compiler error out on it, just give a warning that it's most likely undesired behaviour, a nice way to remind you and catch that issue early on in development.
I suppose compiler warnings have a lot of crossover with linting on multiple scenarios and I guess you could call tslint in the post build actions.
But I think it depends a lot on how big of an impact the issue has and how often the undesired behaviour occurs (does it lead to a bug in most cases? is it easy to spot while running?). If it occurs very frequently and/or is hard to debug, which means it adds frustration and hampers development then it definitely should be a warning.
And in the rare cases that it IS desired (if ever), some '@SupressWarning' annotation or a special comment above it or something to well, surpress the warning, could prevent a long list of warnings that the developer doesn't care about.
In visual studio I rarely look at the warnings anyway, it's usually the squiggly line that gives me pause and make me go 'hey why are you squiggling .. oh yeah that makes sense'. Reviewing warnings afterwards is easily the same as reviewing the output of a linter.
kitsonk commentedon Aug 30, 2015
@drake7707 that is exactly what tslint would allow and there are integrations to several editors. There is already the framework for suppressing warnings which is standard practice in the ES world which tslint supports. (I got the link backwards above, corrected now)
adidahiya commentedon Aug 30, 2015
sounds useful, I filed a tslint FR for this: palantir/tslint#624
side note -- we considered implementing some kind of decorator syntax for suppressing warnings but this would be pretty limited since decorators can only be used in ES6 classes: palantir/tslint#350
RyanCavanaugh commentedon Jul 17, 2020
Works now