Calories Tracker Project — Round 1

Let's start simple. Step by step.

We have a calorie tracker to build. Before we write a single line of code, we need to think about the data. What do we actually want to track? What information matters?

We want to log what we eat. But in what form? Do we care about the color? The store where we bought it? The brand? Some things matter, some don't. So let's think about what's actually relevant — and keep in mind that we can always add more fields later. Starting lean is smarter than starting complete.

At this level, we care about four things: the name of the food, the quantity, the number of calories, and the date we consumed it.

name = "Chicken Breast"
quantity = 200
calories = 175
date = "02.04.2025"

That looks reasonable. But wait — 200 of what? Grams? Milliliters? A unit without a measure is just a number. So we revise:

name = "Chicken Breast"
quantity = 200
measure = "g"
calories = 175
date = "02.04.2025"

Better. Now let's say we log two meals:

name1 = "Chicken Breast"
quantity1 = 200
measure1 = "g"
calories1 = 175
date1 = "02.04.2025"

name2 = "White Rice"
quantity2 = 100
measure2 = "g"
calories2 = 130
date2 = "02.04.2025"

It's hard to explain why this is inefficient — it just becomes obvious when you see it. A tracker runs for months. The number of variables would become unmanageable. So, starting from these same five data points, we organize them more efficiently. Lists feel like a natural step:

food1 = ["Chicken Breast", 200, "g", 175, "02.04.2025"]
food2 = ["White Rice", 100, "g", 130, "02.04.2025"]

And even this makes it clear: with a tracker that runs over a long period of time, the number of lists will become overwhelming. So we move toward a dictionary. The question is: what should the key be? The name, or the date?

Worth noting here — there are rarely wrong answers. There are answers that don't return what you expect, and those are errors. But choosing "date" as a key and understanding the logic behind it, controlling it — that's your call. The result, the implementation effort, the time invested — those are your resources. And the key can always be changed later.

food_dict = {
    "Chicken Breast": [200, "g", 175, "02.04.2025"],
    "White Rice":     [100, "g", 130, "02.04.2025"]
}

It's hard to imagine a real tracker where you type the data like this every time. So let's work on the input side. We'll use input():

food_dict = {}

name     = input("Food name: ")
quantity = input("Quantity: ")
measure  = input("Measure: ")
calories = input("Calories: ")
date     = input("Date: ")

food_dict[name] = [quantity, measure, calories, date]

That's a step forward. But we can immediately take another one — wrapping this in a function. Not just one way. Two. They're not being compared for performance. They're just different. The choice depends on how you want to enter data and what result you expect. Both produce the same output. The decision is yours.

Method 1 — one input at a time

food_dict = {}

def add_food_item():
    name     = input("Food name: ")
    quantity = input("Quantity: ")
    measure  = input("Measure: ")
    calories = input("Calories: ")
    date     = input("Date: ")
    food_dict[name] = [quantity, measure, calories, date]

add_food_item()

We call the function. We enter the data:

Food name: Chicken Breast
Quantity: 200
Measure: g
Calories: 175
Date: 02.04.2025

5 fields entered. 5 times Enter pressed. We check the result:

print(food_dict)
# {'Chicken Breast': ['200', 'g', '175', '02.04.2025']}

Method 2 — everything on one line

food_dict = {}

def add_food_item():
    food_details = input("Enter food details, separated by semicolon: ")
    food_data    = food_details.split(";")
    food_dict[food_data[0]] = [food_data[1], food_data[2], food_data[3], food_data[4]]

add_food_item()

We call the function. We enter everything at once:

Enter food details, separated by semicolon: Chicken Breast;200;g;175;02.04.2025

5 fields entered. 1 time Enter pressed. Same result:

print(food_dict)
# {'Chicken Breast': [' 200', ' g', ' 175', ' 02.04.2025']}

Fewer lines. Faster to enter — at least on the surface. But what if you forget which keyboard layout you're on and use a different character? What if someone else uses the tool and instinctively types a comma instead of a semicolon? What if you change the separator — and somewhere in your data you have "Carrots, celery, apple salad"? What if the quantity is a float and the decimal separator conflicts with your chosen delimiter?

These are real questions. They're part of how we build. There's no single right answer — but the choice has consequences down the line. It's a crossroads.

What are we going to use?