I pretty much think that he meant it based on the variable's name. In the first example, section 2, total_score is pretty self explanatory by its name, while in the second example you gave, in section 4, counter is not so easy to understand in terms of goals and where it is used (what does it count? apples?), but the comment would give an overview over the fact that it counts the total number of occurrences (as mentioned in the article).
I don't think so. The article is about comments, not variable naming. The comments shown here give no more information about the variables' content - they just repeat the name.
I’m a children’s musician and college algebra instructor working on a late-in-life iOS Dev career change. First project: a different kind of calendar for my dementia-challenged elderly mom.
Location
Stillwater, Oklahoma, USA
Education
Master's in Mathematics
Pronouns
he/him
Work
Adjunct Instructor, College Algebra; Children's Musician
The article is about documentation, which encompasses both comments and variable naming. Also, I took each example to be illustrative of a particular point. In point 2, the example went from "bad" to "good" by providing context, while both versions happen to be redundant. In point 4 the example went from "bad" to "good" by removing redundancy. In both cases the code could be further improved by applying both principals. In point 2 the "good" example could be made even better by dropping the comment altogether to remove the redundancy. In point 4 the "good" example could provide even more context with a better variable name (in which case a comment may not be needed), or a more specific comment (occurrences of what?). But I believe the author's intent was to create examples that focus on one issue at a time.
Might want to revise the examples somewhat. In section 2, this is 'good':
Then in section 4, this is marked as 'bad':
I ended up noticing it and was confused about it too. But the rest of the content is very good, thank you for sharing 🦤.
I pretty much think that he meant it based on the variable's name. In the first example, section 2,
total_scoreis pretty self explanatory by its name, while in the second example you gave, in section 4, counter is not so easy to understand in terms of goals and where it is used (what does it count? apples?), but the comment would give an overview over the fact that it counts the total number of occurrences (as mentioned in the article).I don't think so. The article is about comments, not variable naming. The comments shown here give no more information about the variables' content - they just repeat the name.
The article is about documentation, which encompasses both comments and variable naming. Also, I took each example to be illustrative of a particular point. In point 2, the example went from "bad" to "good" by providing context, while both versions happen to be redundant. In point 4 the example went from "bad" to "good" by removing redundancy. In both cases the code could be further improved by applying both principals. In point 2 the "good" example could be made even better by dropping the comment altogether to remove the redundancy. In point 4 the "good" example could provide even more context with a better variable name (in which case a comment may not be needed), or a more specific comment (occurrences of what?). But I believe the author's intent was to create examples that focus on one issue at a time.
Got my point..