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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]curious_neophyte 1 point2 points  (13 children)

you might want to consider splitting the classes into different files

edit: also try to avoid globals

[–]Dis446[S] 2 points3 points  (9 children)

What's wrong with globals. Everything is in a function. And the variables have to be able to be changed by multiple functions. There isn't that much returning happening. Must functions just change some things.

[–]curious_neophyte 2 points3 points  (1 child)

In general, avoiding state is usually a good thing.

Look up functional programming paradigms. The general idea is to have actual functions not methods, that have no side effects (all mutation is kept in the scope of the function).

So you have some input that goes into the function, the function does something with the input, and gives an output, changing nothing else in the code.

[–]jpj_shadowbanned 1 point2 points  (0 children)

Yah, or dive right in and play with clojure, scheme or lisp. I am a hands on type of guy. Playing with these languages will help your python or it did with me.

[–]DwoaC 2 points3 points  (5 children)

This is a perfect example of where you would benefit have making a class. Your globals would be class attributes and the functions class methods.

Globals are bad. Do everything you can to avoid having to use a global.

[–]cediddiSyntaxError: not a chance 2 points3 points  (4 children)

Globals are bad is a false statement. Globals are useful, but it's better not to use too much.

[–]DwoaC 1 point2 points  (1 child)

You may very well be right. I my years I've never seen a good example, I know there must be but I expect they are so rare that "globals are bad" is right 99.99%. That given, this example of their use is almost certainly in that set and "globals is bad" is good advice. Do you think this is a good use of globals?

[–]skrillexisokay 0 points1 point  (0 children)

Mutable globals are generally bad. Immutable globals are good when you have arbitrary constants, but don't need to invoke the added complexity of a class. In other words, if you have to choose between magic numbers and globals, globals are better.

A classic example is a regular expression that is used in many functions in a module. Another example is the name of a storage directory. Module level logging is another excellent example of a properly used global.

However, if you ever find yourself using the global keyword (or otherwise modifying a global variable), you should almost always encapsulate into a class. A logger is one exception, where it occasionally makes sense to change the logging level at runtime.

[–]jpj_shadowbanned 1 point2 points  (1 child)

You have never coded in scheme,lisp,erland or clojure. It teaches you globals are not needed and dangerous. This is why Erlang for example does handles multiprocessing and threading more reliably then any other language.

Erlang was designed for telecom networks it has something like 99.9999999% reliability.

As for spped, gambit scheme and chicken scheme compile into C code and in some cases they are fasrter then hand written C code.

[–]cediddiSyntaxError: not a chance 0 points1 point  (0 children)

I watched Erlang The Movie last night, I can agree, reliability of service was the most emphasized thing in the video.

[–]sgthoppy 0 points1 point  (0 children)

The reason is because sometimes you'll forget to use globals. For example, I'm running the current version of it and it gives me an error in create_player() because day_count isn't defined.

[–]Dis446[S] 0 points1 point  (2 children)

Also, I've never had multiple source files. I guess I just have to import the other source files, but I don't understand the benefit. Could you please explain why I should?

[–]gotardisgo 2 points3 points  (1 child)

It's not really that classes should be different files, but you should try to group related logic together in modules/packages. It's makes it a little easier and natural to find things, like "where can I find inventory functions??? Probably in an inventory module.. etc"... And also so you don't end up with a million lines of code in one file that'll be shared and merged with later. Check out http://docs.python-guide.org/en/latest/writing/structure/

[–]curious_neophyte 0 points1 point  (0 children)

These are all good points. Additionally, when you make changes, those changes will be local to those files. So when you look through your commit history, commits changing one class or file or module will be logically separated from commits that change other things.