There's an old joke among programmers: "There are only two hard things in computer science — cache invalidation and naming things." You don't need to know what cache invalidation is. But the naming part is real, and it shows up on your very first day of writing code.
When I started, I named everything badly. My variables were x, y, n, temp, data, data2. My code worked. But when I opened the same file a week later, I had no idea what any of it meant. I'd written a stranger's program.
Good names are the difference between code you can read next week and code you can't.
Names are notes to your future self
Here are two versions of the same line of Python:
if g >= 3.5 and f < 500:
print("ok")if gpa >= 3.5 and application_fee_usd < 500:
print("Likely a good fit")Both run. Both produce the same result. But only one of them tells you what the program is actually deciding. The second one reads almost like English: "if the GPA is at least 3.5 and the application fee is under 500 dollars, it's likely a good fit."
You are not writing code for the computer. The computer is fine with g and f. You're writing code for the human who reads it next — and that human is almost always you, three weeks from now, trying to remember what you meant.
A short field guide
Some patterns I'd encourage from day one.
Spell out the word. gpa is fine because GPA is a known abbreviation. g is not. fee is OK but ambiguous — fee for what? application_fee is better.
Add units when they matter. Money, time, and distance all bite you if you forget the unit. application_fee_usd is safer than application_fee. deadline_days_away is clearer than deadline. duration_minutes removes any guessing.
Use two words when one isn't enough. A single-word variable name is often a single-word lie. total — total of what? total_cost_usd or total_applications_submitted is honest.
Booleans should sound like questions. A variable that's either True or False reads best as a yes-or-no question. eligible_for_chevening is great. flag1 is a horror. is_deadline_passed, has_english_test, is_fully_funded — each one tells you what True means.
Lists should be plural. If it's a collection, name it like a collection. universities, not university. Then your for loops read naturally: for university in universities.
A small refactor
Here's a snippet from a real first-week assignment, before and after.
Before:
g = 3.7
f = 80
t = 30
e = 220
total = f + t + e
if g > 3.5 and total < 500:
print("yes")After:
gpa = 3.7
application_fee_usd = 80
transcript_fee_usd = 30
english_test_usd = 220
total_cost_usd = application_fee_usd + transcript_fee_usd + english_test_usd
if gpa > 3.5 and total_cost_usd < 500:
print("Likely a good fit for this scholarship.")The second version is longer. That's the point. Code is read many more times than it is written. Six extra characters today save you ten minutes of re-reading next week.
The same idea applies to functions and files
Functions are the same story. calc() tells you nothing. calculate_total_application_cost() tells you everything. When in doubt, a function name should be a small verb phrase — generate_email, check_eligibility, load_scholarships_from_csv.
Files too. script.py versus scholarship_tracker.py. untitled1.ipynb versus week2_dictionaries_practice.ipynb. You will thank yourself.
Naming is taste, and taste is trained
Here's the encouraging part: nobody is born with good naming instincts. They come from reading a lot of code and noticing what felt clear and what didn't. Every time you open someone else's project and think "oh, that's a nicer name than I'd have used," your taste improves a tiny bit.
So don't worry about getting every name perfect on day one. Just try to use real words. Add a unit when it matters. Make booleans sound like questions. The rest will come from practice and from reading.
And if I'm reviewing your code and I scribble "rename this" in the margin — don't take it personally. I'm just trying to make your code easier for the next person to read. Even if that person is you.