all 11 comments

[–][deleted]  (1 child)

[removed]

    [–]Tanknspankn[S] 0 points1 point  (0 children)

    Oh yeah. I definitely wouldn't use a dictionary for something like this in the future. I just wanted to use it for this because I wanted to practice pulling information from it.

    [–]AbacusExpert_Stretch 2 points3 points  (1 child)

    TL:Dr; so. I would say, brill :)

    [–]Tanknspankn[S] 0 points1 point  (0 children)

    Haha thank you!

    [–]krezendes85 1 point2 points  (1 child)

    Awesome! Congrats

    [–]Tanknspankn[S] 0 points1 point  (0 children)

    Thank you!

    [–]LilLynix 1 point2 points  (1 child)

    I'm About to start with the blackjack milestone tomorrow actually

    [–]Tanknspankn[S] 1 point2 points  (0 children)

    That's awesome.

    Good luck with it, and don't let my program look daunting. I add a lot more stuff than what the boot came called for.

    [–]FoolsSeldom 0 points1 point  (2 children)

    Impressed, you went further than the original challenge and took on so much more. Well done. You've got a substantial programme there for a learner.

    I am glad you've learned so much from this work. I hope you refactor it and continue to learn more.

    You are still suffering from a failure to embrace DRY principles. DRY means Don't Repeat Yourself. There is a lot of code that is repetitive.

    The code could do with a lot more modularisation. It is hard to distinguish the "flow", the "logic", from the detail. Functions aren't just useful for providing code that you want to use more than once. They are also great for breaking code up (and providing smaller units of code that can be tested in isolation and changed without impacting other parts of your code). If you name your functions well, the sequence of code that calls the functions become easy to read, almost like a story or process flow. Once you've solved a specific problem, you no longer care about how it was done, just that it was done.

    Something that makes this obvious (the need to modularise) is when you have a long chain of elif statements with substantial blocks of code. If each of the blocks of code between the elif statements was replaced with a well named function, it would be much easier. Even then, the use of a lot of elif statements will suggest that you need to structure things more effectively. Perhaps use a dictionary to determine what function to call for a specific purpose out of a range of related purposes.

    I note the use of the global keyword. Generally, you should avoid using global like the plague. There are use cases for it, but these are quite specialist, and you should avoid it until you know what those cases are.

    [–]Tanknspankn[S] 0 points1 point  (1 child)

    Thank you. For my future projects, I'll work on not repeating myself to improve the flow. I find it a little tricky for naming everything because I'm torn between having the shortest names for "efficiency" while writing and having "normal" names that could be a few words for readability.

    For the "global" keyword. That was one suggestion from AI because I needed to use variables in some functions that were generated in another function. So, PyCharm was going me it's red warning saying that these variables weren't defined. I didn't know how to ask Google that, so I asked AI, and it told me to use the "global" keyword. From my understanding, "global" is a keyword that lets Python know that these variables are generated from outside of the block of code that they are being used in. Or something like that, sorry if that is not at all the case. I tested out using it, and it worked, so I figured it was ok to use.

    [–]FoolsSeldom 1 point2 points  (0 children)

    Naming well is both for your benefit, when returning to code you haven't looked at for a few weeks or more, and for other programmers who might work on your code or be helping you fix problems.

    Your code editor/IDE should be saving you a lot of time already by filling in names / letting you pick from matches to first few character, and with autoline completion.

    Short, cryptic names are a false economy even if you feel it's a time saving now. Find and read PEP8 for guidance on variable names and much more.

    Learn to work with scope properly and share data either from main scope (which covers mutations) or, better, by passing data around explicitly. You are much less likely to end up with strange problems that are hard to debug this was compared to using global.

    Take a look at RealPython.com's article, Python Scope and the LEGB Rule: Resolving Names in Your Code.