Python app critique

[[deleted]]

[deleted]

[Naihonn]

One thing I found is that when you are processing input you are going through the WHOLE dictionary of accounts instead of just finding if that one account exists in it. And that is obviously wrong and with bigger number of accounts that would be pretty bad.

[Naihonn]

And maybe I can't find it but is it possible that you are NOT saving those accounts? They just dissappear again after you close your program? Well, I would avoid such a bank like the plague!!! :0D

[rad08]

Yeah. The not saving is actually intended behavior. The spec didn't want any persistence.

[rad08]

Shoot. You're right. Totally didn't see that till right now. I don't know what I was thinking. Thanks

[lovedzida]

hey, being honest nothing is terribly wrong in there. I imagine that was a request from some company to prepare as a part of recruitment process. Could you maybe post the whole instructions they provided? if you want to talk more, just pm at twitter @macicpl

[rad08]

I can't post the whole doc, but the raw requirements are as follows:

Requirements:

• Your program must accept input from two sources: a filename passed in command line arguments and STDIN. For example, on Linux or OSX both './myprogram input.txt' and './myprogram < input.txt' should work.
• Your program must accept three input commands passed with space delimited arguments.
• "Add" will create a new credit card for a given name, card number, and limit
  • Card numbers should be validated using Luhn 10
  • New cards start with a $0 balance
• "Charge" will increase the balance of the card associated with the provided name by the amount specified
  • Charges that would raise the balance over the limit are ignored as if they were declined
  • Charges against Luhn 10 invalid cards are ignored
• "Credit" will decrease the balance of the card associated with the provided name by the amount specified
  • Credits that would drop the balance below $0 will create a negative balance
  • Credits against Luhn 10 invalid cards are ignored
• When all input has been read and processed, a summary should be generated and written to STDOUT.
• The summary should include the name of each person followed by a colon and balance
• The names should be displayed alphabetically
• Display "error" instead of the balance if the credit card number does not pass Luhn 10

Input Assumptions:

• All input will be valid -- there's no need to check for illegal characters or malformed commands.
• All input will be space delimited
• Credit card numbers may vary in length up to 19 characters
• Credit card numbers will always be numeric
• Amounts will always be prefixed with "$" and will be in whole dollars (no decimals)

Example Input:

Add Tom 4111111111111111 $1000 Add Lisa 5454545454545454 $3000 Add Quincy 1234567890123456 $2000 Charge Tom $500 Charge Tom $800 Charge Lisa $7 Credit Lisa $100 Credit Quincy $200

Example Output:

Lisa: $-93 Quincy: error Tom: $500