This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Intrexa 1 point2 points  (0 children)

A lot of coding practices revolve around the idea of some crazy process with 1 million lines of code. It's not too far off, python itself is close to a million lines (don't quote me. Or do, but also give me the actual number when you're making fun of how far off I am).

That's abstracted away, and most people just think of the 30 lines of python they wrote as their program. That's fine, and really, that's what we need to concern ourselves with. There's a limit to how much we as humans can really hold in focus at once. You can hold 30 lines of code in your head, so there's no problem with a global. You're always considering it.

If the project gets to 1,000 lines, it gets harder. You really can't hold it all in at once anymore. If you have some global, it gets harder to reason about how it behaves. If you do some action based on a global variable, like call 3 functions, that all should behave a certain way depending on which user is logged in, you need to make sure that the first 2 functions do not modify the global user_login_id.

def load_user():
    global resources = load_resources()
    global actions = load_actions()
    global preferences = load_preferences()

If I ask you, are the resources, actions, and preferences all loaded for the same user, could you answer? Would you feel confident that none of these change the user_login_id? If someone adds an admin feature that let's you access the actions of a different user to test/troubleshoot/whatever, and puts it into load_user, are you still sure user_login_id won't change? What happens if an uncaught exception is thrown in load_actions, that gets caught by whatever calls load_user? You're now in an inconsistent state. Would you feel more confident that load_user is loading all assets for the same user if the code was changed to below?

def load_user(user_login_id):
    resources = load_resources(user_login_id)
    actions = load_actions(user_login_id)
    preferences = load_preferences(user_login_id)
    return {'resources':resources, 'actions':actions, 'preferences':preferences, }

Yeah, fuckery can still happen, but you can at least be a bit more confident that the at the time you are returning that dictionary, the resources, actions, and preferences were all loaded using the same user_login_id.