I often use `fgets` in small C projects to read user input, then convert that text into the appropriate data type with functions such as `strtod`. For example, in a temperature-conversion program, the user selects a conversion such as Kelvin to Fahrenheit and enters a temperature.
I'm unsure how to name the variables at each stage. Should the buffer from `fgets` be called something like `temperature`, followed by a name such as `real_temperature` or `dbl_temperature` after conversion? Or is it clearer to use a temporary name such as `input`, `line`, or `buffer` for the raw text and reserve `temperature` for the resulting `double`?
There doesn't seem to be a standard approach for two variables that represent the same information at different stages and with different types. What naming convention would make the code easiest to understand and maintain?
4 Answers
Don’t tie the temporary variable’s name to the way you happened to read the data. A name like `line`, `input`, or `buffer` works well for text that is immediately parsed and then discarded. Once the value has meaning in the program, give it a meaningful domain name such as `temperature` or `source_temperature`.
For example, `input` can hold the line from `fgets`, while `source_temperature` holds the parsed `double`. This keeps the code flexible if you later replace `fgets` with another input method.
A useful rule is: use meaningful names for values shared across a wider scope, and concise names for short-lived locals. Loop counters can usually be `i`, while a value used throughout a function should explain its purpose. For this case, something as simple as `line` for the `fgets` buffer and `temperature` for the parsed number is reasonable, provided the scopes make the transition obvious.
Prefer naming the value according to what it means rather than its C type. `temperature_kelvin` tells you more than `double_temperature`, because the unit is important to the calculation while the implementation type may not be.
Type-based prefixes such as Hungarian notation (`szTemp` or `dbTemp`) are an older convention and generally aren’t necessary. Names like `temperature_input`, `temperature`, and `temperature_result` are clearer. In larger programs, a dedicated temperature type could also keep units from being mixed accidentally.
There’s no universal naming standard, so use the level of detail that matches the variable’s scope and lifetime. If the string exists only to be validated and converted immediately, `input` or `line` is perfectly adequate. If it will be reused later, choose a more specific name such as `temperature_text` or `temperature_input`.
For values that represent different concepts, include that distinction in the name. For example, `source_unit`, `target_unit`, `source_temperature`, and `result_temperature` communicate more than names based only on the data type.
Longer names can feel awkward at first, but they’re worthwhile for values that survive beyond a few lines. I’ve found that explicit names make older code much easier to understand.
That approach is especially convenient in small functions: use a short name for a temporary value and a descriptive name for anything that remains in use. A raw `line` becoming `temperature` is usually clearer than encoding the C type into both names.