Suggestion: disallow use before initialization

[neilgalarneau]

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.

[danquirk]

I think we have a bug on this already but I'm having trouble finding it. It's one part of #2176

[neilgalarneau]

@mhegazy Duplicate of what?

#2176 doesn't mention "Use before Initialization".

[mhegazy]

sorry about that. fixing labels.

[drake7707]

+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]

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 @adidahiya

[drake7707]

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]

@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]

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]

Works now