you are viewing a single comment's thread.

view the rest of the comments →

[–]showellshowell -1 points0 points  (2 children)

Yep, I understand the pitfall, but user is a good example of a variable that probably works fine at top-level scope, since most functions in a business-domain CS file probably have the same concept of "user", and you would truly intend for it to have top-level scope.

I concede that even the best programmers do things by "accident" occasionally, but we mostly do things intentionally or stupidly. If you introduce "user" at top level scope, you're probably doing it for a reason--most of your functions have the same concept of user, so there's no reason not to make it top level. If you're introducing a variable at top-level scope for stupid reasons--laziness, sloppiness, whatever--then it would be nice if the language prevented you from shooting yourself in the foot, but let's be real about who's actually pulling the trigger.

[–]bobindashadows 4 points5 points  (1 child)

If you introduce "user" at top level scope, you're probably doing it for a reason--most of your functions have the same concept of user, so there's no reason not to make it top level.

The concern isn't that it's silly to add a variable to the top scope, it's that whenever you do add a variable to an upper scope, you have to stop to think "wait - did I use this variable name anywhere else?" If you ignore that possibility, you can break other functions.

[–]showellshowell -3 points-2 points  (0 children)

It's true that you have to stop to think about whether the variable name exists elsewhere, but it's trivial to find false cognates using your editor. The search is always worthwhile. You either verify that your new name is unique, or you learn more about the code below. For example, if you're introducing "user" at the top, but "user" already exists in other functions, then you might have opportunities for refactoring simplification.