Choosing clear names
A name tells a reader what a value or a piece of code means. score gives a useful clue. x could mean a score, a position, a price, or almost anything else.
You write code once, but you may read it many times. Clear names help your future self as well as someone helping you.
Label the boxes
Imagine two boxes labelled “stuff” and “more stuff.” Finding your drawing pencils would take longer than if one box said “drawing pencils.” Variables are not literally cardboard boxes, but meaningful labels help in the same way.
A good name describes the job of the value. Include a unit when confusion is likely: distancePixels and waitSeconds explain more than amount. Keep names reasonably short without turning them into puzzles.
Read this calculation
# language: en
let starsCollected = 4
let pointsPerStar = 3
let totalScore = starsCollected * pointsPerStar
say "Score:", totalScore
These names explain both numbers and the resulting score. The capitals mark word boundaries; this writing style is called camelCase. It is a choice for your own names, not a requirement that every name must look this way.
Predict, then run
How many points does each star give? What output should appear?
Score: 12
You can answer the first question by reading the name pointsPerStar, without needing a separate comment.
Your challenge
Change the game from stars to shells. Rename the variables to match and update every use of each renamed variable. Keep the numbers unchanged. The result should still be twelve.
A common mistake
Renaming a declaration but forgetting a later use can leave an unknown name. Pliro also distinguishes uppercase and lowercase letters: score and Score are different identifiers.
Do not use a language keyword such as if as your own name. Avoid using a built-in name such as say for ordinary data; that can hide the function you wanted to call. Your own identifiers are not automatically translated when Pliro converts source syntax.