Change Details

Ref T12822. The next change hits these warnings but I think neither is a net positive. The "function called before it is defined" error alerts on this kind of thing: ``` function a() { b(); } function b() { } a(); ``` Here, `b()` is called before it is defined. This code, as written, is completely safe. Although it's possible that this kind of construct may be unsafe, I think the number of programs where there's unsafe behavior here AND the whole thing doesn't immediately break when you run it at all is very very small. Complying with this warning is sometimes impossible (if you have two functions which are mutually recursive). Although compliance is usually possible, it forces you to define all your small utility functions at the top of a behavior. This isn't always the most logical or comprehensible order. I think we also have some older code which did `var a = function() { ... }` to escape this, which I think is just silly/confusing. Bascially, this is almost always a false positive and I think it makes the code worse more often than it makes it better. --- The "unused function parameter" error warns about this: ``` function onevent(e) { do_something(); ``` We aren't using `e`, so this warning is correct. However, when the function is a callback (as here), I think it's generally good hygiene to include the callback parameters in the signature (`onresponse(response)`, `onevent(event)`, etc), even if you aren't using any/all of them. This is a useful hint to future editors that the function is a callback. Although this //can// catch mistakes, I think this is also a situation where the number of cases where it catches a mistake and even the most cursory execution of the code doesn't catch the mistake is vanishingly small.

Ref T12822. The next change hits these warnings but I think neither is a net positive. The "function called before it is defined" error alerts on this kind of thing: ``` function a() { b(); } function b() { } a(); ``` Here, `b()` is called before it is defined. This code, as written, is completely safe. Although it's possible that this kind of construct may be unsafe, I think the number of programs where there's unsafe behavior here AND the whole thing doesn't immediately break when you run it at all is very very small. Complying with this warning is sometimes impossible -- at least without cheating/restructuring/abuse -- for example, if you have two functions which are mutually recursive. Although compliance is usually possible, it forces you to define all your small utility functions at the top of a behavior. This isn't always the most logical or comprehensible order. I think we also have some older code which did `var a = function() { ... }` to escape this, which I think is just silly/confusing. Bascially, this is almost always a false positive and I think it makes the code worse more often than it makes it better. --- The "unused function parameter" error warns about this: ``` function onevent(e) { do_something(); ``` We aren't using `e`, so this warning is correct. However, when the function is a callback (as here), I think it's generally good hygiene to include the callback parameters in the signature (`onresponse(response)`, `onevent(event)`, etc), even if you aren't using any/all of them. This is a useful hint to future editors that the function is a callback. Although this //can// catch mistakes, I think this is also a situation where the number of cases where it catches a mistake and even the most cursory execution of the code doesn't catch the mistake is vanishingly small.

Ref T12822. The next change hits these warnings but I think neither is a net positive. The "function called before it is defined" error alerts on this kind of thing: ``` function a() { b(); } function b() { } a(); ``` Here, `b()` is called before it is defined. This code, as written, is completely safe. Although it's possible that this kind of construct may be unsafe, I think the number of programs where there's unsafe behavior here AND the whole thing doesn't immediately break when you run it at all is very very small. Complying with this warning is sometimes impossible (if-- at least without cheating/restructuring/abuse -- for example, if you have two functions which are mutually recursive). Although compliance is usually possible, it forces you to define all your small utility functions at the top of a behavior. This isn't always the most logical or comprehensible order. I think we also have some older code which did `var a = function() { ... }` to escape this, which I think is just silly/confusing. Bascially, this is almost always a false positive and I think it makes the code worse more often than it makes it better. --- The "unused function parameter" error warns about this: ``` function onevent(e) { do_something(); ``` We aren't using `e`, so this warning is correct. However, when the function is a callback (as here), I think it's generally good hygiene to include the callback parameters in the signature (`onresponse(response)`, `onevent(event)`, etc), even if you aren't using any/all of them. This is a useful hint to future editors that the function is a callback. Although this //can// catch mistakes, I think this is also a situation where the number of cases where it catches a mistake and even the most cursory execution of the code doesn't catch the mistake is vanishingly small.