Clean Code: Naming functions and variables

[dev-ameen007]

Describe your suggestion

Under the section "Naming function and variables", the guideline suggests that const isSelected = true; is bad practice because it starts with "is", which goes against the recommendation that "variables should always begin with a noun or an adjective". I believe this might be a misconception. In fact, for boolean variables, it's actually a common and good practice in the JavaScript community to prefix with is, has, or can.

// ✅ Prefix with: is, has, can
let isPerson = true;
let hasAge = true;
let canDance = true;

These prefixes make it clear that the variable represents a boolean value, thereby enhancing the readability of the code. This convention is widely accepted and recommended in various coding standards and guidelines.

For instance, a variable like isSelected clearly indicates that it holds a boolean value, representing whether something "is selected" or not. This makes the code more understandable to the reader.

Here are some references that support this convention:

• Tips on naming boolean variables - Cleaner Code
• StackOverflow: Naming booleans
• Guideline 1: Avoid negative names for standalone variables
• How to give your boolean variables a better name

I believe an update to this guideline in your curriculum would be beneficial for learners, especially beginners who are trying to grasp good coding practices. Thank you for considering my suggestion.

Path

Foundations

Lesson Url

https://www.theodinproject.com/lessons/foundations-clean-code

Checks

• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

(Optional) Discord Name

developer007

(Optional) Additional Comments

No response

[Lofty-Brambles]

I think the context with regards to which this example comes into context is necessary here. Usually, flags (in this case, refered to as boolean variables) themselves aren't usually a great idea, but here, one can mistake them for functions (like if isSelected :: condition -> bool is a thing).
Since we are using a convention, the better approach would be to eliminate the need of such a variable itself, but in case it isn't possible, XIsSelected would be a better approach. Maybe mentioning that would be a good idea?

[dev-ameen007]

@Lofty-Brambles Thank you for your insightful response. As a beginner in the field, I appreciate your perspective on the potential confusion that can arise from using is, has, or can as prefixes for boolean variables.

In my research, I've found that the use of is, has, and can as prefixes is widely accepted in the JavaScript community and is a common practice. These prefixes enhance code readability by clearly indicating that the variable represents a boolean value.

It's worth noting that the example code you provided, isSelected :: condition -> bool, seems to be written in Haskell, not JavaScript. In the context of this curriculum focused on JavaScript conventions, the use of type annotations and the specific syntax does not align with JavaScript practices.

After a little more research, it appears to be a topic that sparks debates within the programming community, with varying opinions on whether to adopt these prefixes or opt for alternative naming conventions.

Even when considering a different naming convention for the curriculum, it's important to acknowledge that the prefixes is, has, and can for boolean variables are well-established conventions in the JavaScript community. As a learner, staying aware of these debates is valuable, especially for new learners, to prevent confusion when encountering codes written by other developers who use this convention.

I think considering these facts and updating the curriculum to provide a broader understanding of this topic would be beneficial.

[CouchofTomato]

@TheOdinProject/javascript Can someone respond please.

[MaoShizhong]

Closing in favour of #28643