- 01Setting Up (What You'll Need)
- 02Creating Variables
- 03Conditionals (if Statements)
- 04Loops (for Statements)
- 05Creating Functions
- 06Working with Arrays
- 07Working with Objects
- 08Loops (while Statements)
- 09Working with Strings
- 10Using Classes (Object-Oriented Programming)
- 11Error Handling (try...catch)
- 12Destructuring and the Spread Syntax
- 13Async Code (Promise / async & await)
- 14Advanced Array Methods (filter and reduce)
- 15The switch Statement
- 16The Ternary Operator
- 17Inheritance (Extending Classes)
- 18How to Write Comments
- 19Logical Operators (AND, OR, NOT)
- 20Constants (Making Read-Only Values with const)
- 21Splitting and Joining Strings (split and join)
- 22Null-Safe Syntax (?? and ?.)
- 23Searching Arrays and Collections (includes and find)
- 24Transforming Arrays with map
- 25Two-Dimensional Arrays (Table-Shaped Data)
- 26Building a Custom Error Class
- 27Default Arguments (Setting Initial Values for Parameters)
- 28Using Set (Collections)
- 29Verifying Correctness with assert (Your First Step Into Testing)
- 30Higher-Order Functions (Passing a Function as an Argument)
- 31Stacks and Queues (Basic Data Structures)
- 32The Basics of Type Conversion (Casting)
- 33Introduction to Regular Expressions (Pattern Matching)
- 34The Binary Search Algorithm
- 35Building a Caesar Cipher (a Letter-Shifting Cipher)
- 36Understanding How Bubble Sort Works
- 37Building and Displaying Dates (Basic Year/Month/Day Operations)
- 38Writing Several Unit Tests Together (Multiple Test Cases)
- 39Speeding Up Calculations with Memoization (Caching)
- 40Normalizing Strings (trim and Case Unification)
- 41The Difference Between Shallow Copy and Deep Copy
- 42The Basics of Enums (Enumerated Types)
- 43Flattening Arrays (flatten)
- 44Reversing a String and Checking for a Palindrome
- 45Pairing Up Two Arrays (a zip Operation)
- 46Rounding Numbers (floor, ceil, and round)
- 47Multi-Line Strings (Template Literals)
- 48Returning Multiple Values from a Function (Array Destructuring)
- 49Finding the GCD and LCM (the Euclidean Algorithm)
- 50Formatting Numbers (Digit Alignment and Decimal Precision)
- 51Cleanup Processing with try/catch/finally
- 52Writing Type-Agnostic, General-Purpose Functions
- 53The Basics of Map (an Object for Key-Value Pairs)
- 54Generating Random Numbers
- 55Bitwise Operations (AND, OR, XOR, and Shift Operations)
- 56Using static (Static Class Properties and Methods)
- 57Waiting a Fixed Amount of Time (setTimeout and await)
- 58Watch Out for Floating-Point Rounding Error
- 59Transforming and Flattening at Once with flatMap()
- 60FizzBuzz (the Classic Practice Problem)
- 61Checking Whether a Number Is Prime
- 62Set Operations with Set (Union, Intersection, and Difference)
- 63Converting Number Bases (Binary and Hexadecimal)
- 64Checking That Brackets Match (an Application of Stacks)
- 65Checking for an Anagram
- 66Checking Whether a Year Is a Leap Year
- 67Converting Temperature (Celsius ⇄ Fahrenheit)
- 68Finding the Prime Factorization
- 69[Applied] Build a Simple To-Do List Tool
How to Write Comments
In this lesson you'll learn how to write comments in JavaScript so you can write code that's easy to understand even when you come back to it later. This is for beginners searching "JavaScript how to comment out."
A comment is a "note for humans" that has no effect on how the program runs. You write comments so that you (or someone else) can understand the code more easily later. // starts a single-line comment, and /* */ wraps a multi-line comment. Code written inside a comment doesn't get executed, so comments are also often used to temporarily disable code (commenting it out).
The sample code adds an explanation of a variable with a single-line comment, and writes a longer explanation with a multi-line comment. Adding a short note to the right of, or above, a variable — like // price of the item (yen) — is a style used very often in real projects. Comments can be written in either English or your team's preferred language, but the basic rule is to follow your team's conventions.
A common beginner stumbling block is writing so many comments that the code actually becomes harder to read. "What is happening" can often be understood just by reading the code itself, so it's more effective to use comments for "why this processing is needed" instead. Conversely, complex processing should get comments proactively — it's about quality over quantity.
In real development, whether or not comments exist makes a huge difference when working as a team. When you or a teammate looks back at the code months later, a comment that conveys the original intent can drastically speed up fixes and bug investigations. How well you write comments is treated as part of your real-world coding skill.
Many code editors have a keyboard shortcut for commenting out a selected range all at once, which is very handy when you want to temporarily disable code to check how something behaves. It's well worth using actively.
A special comment format called JSDoc (written as /** ... */, describing a function's explanation, arguments, and return value) causes many editors to automatically pop up that function's description, improving efficiency for team development.
💡 Anything passed to console.log() appears in the output below.
