5 ms·

I don't see how it is "actively harmful" to use this style. I'll defend the style and say I think either is fine from an objective standpoint, the advantage of

by veltas 5y ago

I don't see how it is "actively harmful" to use this style. I'll defend the style and say I think either is fine from an objective standpoint, the advantage of declaring near the top and leaving uninitialised is that it means all assignments/values are separate and slightly clearer in code, type annotations are clutter. But likewise it's not that much clutter and you can get used to it (and it's conventional in many other languages). Only in very large functions does it significantly 'hide' the declarations and the type information from where they're used, and so arguably that encourages you to not write very large functions with lots of different variables! But don't pick on this point and say "the limitation becomes a 'feature'", I'm just saying with most good code this doesn't matter, not that it's 'good' that it's harder to write long functions, yes that is a limitation, I just don't think it's a significant one for good code. So I don't see how either is objectively superior. I recommend this style because since there is not a huge difference between the two, I prefer what is conventional.

jcelerier 5y ago
It's very much not ok : it encourages reusing a single variable for multiple uses (think loop index for two successive loops). I can't count the number of bugs I've seen because of that, of someone forgetting that there was already a 'ret' or 'i' variable defined at the top and reusing it directly when it should have been cleared... Minimizing the scope of variables and introducing sub-scopes with braces, makes this problem almost entirely disappear.
- veltas 5y ago
  In my own experience writing and reviewing professional or wild code, a variable called 'i' that gets used for different loops in a function is pretty harmless, if it's reused in a consistent manner, such as only being used as an iterator for top-level loops. Is that re-use with older style declarations really such a sin? And your rule for safer variables with minimal scoping requires the programmer to understand the lifetime and usage of different variables, and appreciate why it's bad to re-use things in a confusing way across a function. But, if they understand that then surely they can already write good code: with or without minimal scoping? What's the difference? Yes, if they attempt to use a variable with one name and in a different block where it means something else then they might get a syntax error (or just visually notice it's out of scope). Why do you assume this error will help them correctly determine whether the same-name-variable is unrelated or just happens to start with more nested scope than it should finish? Or, rather, why do you think the scoping specifically is what will help them get this right? Maybe just drawing their attention to the need to give different names to disambiguate, or to keep better attention to the meaning of a variable throughout a function, is what's helping?
  - jcelerier 5y ago
    > And your rule for safer variables with minimal scoping requires the programmer to understand the lifetime and usage of different variables, and appreciate why it's bad to re-use things in a confusing way across a function. No, there is nothing to understand: the rule to minimize a variable's scope is mechanical. > But, if they understand that then surely they can already write good code: with or without minimal scoping? What's the difference? No. It's impossible to assume that even the very best programmer writes good code consistently, thus every possibility for failure must be automatized or mechanized.
    - veltas 5y ago
      > No, there is nothing to understand: the rule to minimize a variable's scope is mechanical. I tried to explain my answer to this in my third paragraph. > It's impossible to assume that even the very best programmer writes good code consistently, thus every possibility for failure must be automatized or mechanized. This is a strawman, if I thought the feature was useful to prevent this I would give it more consideration. I have already attempted to explain why I don't think conservative scoping aids bad/confusing variable re-use.

by veltas 5y ago

jcelerier 5y ago

It's very much not ok : it encourages reusing a single variable for multiple uses (think loop index for two successive loops). I can't count the number of bugs I've seen because of that, of someone forgetting that there was already a 'ret' or 'i' variable defined at the top and reusing it directly when it should have been cleared... Minimizing the scope of variables and introducing sub-scopes with braces, makes this problem almost entirely disappear.

veltas 5y ago
In my own experience writing and reviewing professional or wild code, a variable called 'i' that gets used for different loops in a function is pretty harmless, if it's reused in a consistent manner, such as only being used as an iterator for top-level loops. Is that re-use with older style declarations really such a sin? And your rule for safer variables with minimal scoping requires the programmer to understand the lifetime and usage of different variables, and appreciate why it's bad to re-use things in a confusing way across a function. But, if they understand that then surely they can already write good code: with or without minimal scoping? What's the difference? Yes, if they attempt to use a variable with one name and in a different block where it means something else then they might get a syntax error (or just visually notice it's out of scope). Why do you assume this error will help them correctly determine whether the same-name-variable is unrelated or just happens to start with more nested scope than it should finish? Or, rather, why do you think the scoping specifically is what will help them get this right? Maybe just drawing their attention to the need to give different names to disambiguate, or to keep better attention to the meaning of a variable throughout a function, is what's helping?
- jcelerier 5y ago
  > And your rule for safer variables with minimal scoping requires the programmer to understand the lifetime and usage of different variables, and appreciate why it's bad to re-use things in a confusing way across a function. No, there is nothing to understand: the rule to minimize a variable's scope is mechanical. > But, if they understand that then surely they can already write good code: with or without minimal scoping? What's the difference? No. It's impossible to assume that even the very best programmer writes good code consistently, thus every possibility for failure must be automatized or mechanized.
  - veltas 5y ago
    > No, there is nothing to understand: the rule to minimize a variable's scope is mechanical. I tried to explain my answer to this in my third paragraph. > It's impossible to assume that even the very best programmer writes good code consistently, thus every possibility for failure must be automatized or mechanized. This is a strawman, if I thought the feature was useful to prevent this I would give it more consideration. I have already attempted to explain why I don't think conservative scoping aids bad/confusing variable re-use.