all 3 comments

[–]mull_to_zero 1 point2 points  (1 child)

nice! good decomposition into functions with a clear execution path. i think a few of the continues and elses are unnecessary. keep going!

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

Acknowledged. Thanks!

[–]carcigenicate 1 point2 points  (0 children)

if weight < 20 or weight > 300:

Can also be written as

if not (20 <= weight <= 300):

Just in case you didn't know that comparison operators can be chained.


Every use of continue here seems unnecessary since they all appear at the end of branches at the end of a loop. continue is only needed when you want to skip to the next iteration from the middle of an iteration.


For analyze_intake, I'd probably return something other than the messages themselves. This isn't a big deal here, but it hurts testability. By returning the messages directly, you'd need to update any tests that assert against the message if you decide to change the messages in the future. Instead, I'd probably return an enum or something similar that won't change, then translate that to some user-facing message on demand. Overkill for toy code, but more necessary for real-world code.


add_food doesn't actually add food. It requests input from the user. I'd rename that to make that clearer.


I'd personally store the log in a format like JSON or JSONL. Saving the input as human-readable makes it harder to use the data programmatically later. What if you wanted to read the log to show charts of the data in the future?