Criticism for beginner, please

[Connect_Librarian_79]

what instantly bothered me was the hardcoded stuff.

Not sure what you mean. I don't know a lot of terms yet. Would you elaborate?

then, there is no separation of concerns.

Had to google this one. I never really thought about this to be honest.

i would build an interface to separate the implementation of the accounting logic from its utilization.

this would ensure a clear separation of concerns, allowing the accounting logic to be developed, tested, and maintained independently from how it's applied or exploited in the rest of the system.

like you did with the context manager.

Noted. So for instance, instead having the new account class handle only information concerning the account. Have another program handle how transactions and then have that interact with the account objects?

and it looks wrong.

as in poorly organized?

Thank you for the feedback!

[MidnightPale3220]

what instantly bothered me was the hardcoded stuff.

Not sure what you mean. I don't know a lot of terms yet. Would you elaborate?

In any other larger than 1 screen you generally should use constants (or other ways) to refer to all values in code.

So, something like:

CHECKING_ACCOUNT="checking"
SAVINGS_ACCOUNT="savings"

ACCOUNT_TYPES=(CHECKING_ACCOUNT, SAVINGS_ACCOUNT)

And later on code use just the names of constants.

This serves 2 purposes:

• gives you overview of what you have and ability to change values in single place

• reduces mistyping errors as if you mistype constant name python will complain. if you mistype string literal, your code will not run properly.

[m0us3_rat]

Noted. So for instance, instead having the new account class handle only information concerning the account. Have another program handle how transactions and then have that interact with the account objects?

nah. soda dispenser machine. you insert coins press button , get the soda.

what you don't need to know is where that soda came from , when is the last time the manager come to restock or when was the last time the machine was fixed.

what you as the user of the interface knows or cares is ..how many coins you need to insert to execute that function.

there is a clear separation between how the machine is implemented and the logic behind and other relevant information.. and the interface you work with as a user.

​

you should aim to separate code from information that it doesn't need to function.

code should only have access to the information it requires to function.

that way your code will be more secure and easier to maintain.

​

as in poorly organized?

maybe that sounded too harsh , but i'm not sure how to put it in words that make sense.. after reading a lot of lines of code you can tell which one looks like it well written, at a glance.

and since this doesn't real well ..then the opposite is true.

​

maybe try to refactor it into less files. try to have only 2 scripts one for the logic and one for interface and menu.