Java Comments Explained — Types, Best Practices and Common Mistakes
Every professional Java codebase you'll ever open is full of them. Comments are one of the first things a senior developer looks at when they review your code — not to see if you commented everything, but to see if you commented the right things. They reveal how clearly you think, how much you care about the next person reading your work, and whether you understand what your own code is actually doing. That's a lot of weight for a few lines that the compiler throws away.
The real problem comments solve is the gap between what code does and why it does it. A machine can read your logic perfectly fine — it doesn't need explanations. But six months from now, when you come back to fix a bug at 11pm, you are not going to remember why you wrote that weird if-condition. Comments bridge that gap. They turn code from a wall of symbols into a story a human can follow.
By the end of this article you'll know all three types of Java comments, exactly when to use each one, how to write comments that actually help instead of clutter, and the specific mistakes that make experienced developers cringe when reviewing beginner code. You'll leave with habits that will make you look like a professional from day one.
Single-Line Comments — Your Quick Margin Notes
A single-line comment starts with two forward slashes: //. Everything after those two slashes on that same line is completely ignored by Java. The moment you hit Enter and move to the next line, you're back in 'real code' territory.
Use single-line comments for short, punchy explanations — things you can say in one breath. They're perfect for explaining a tricky calculation, a magic number, or a decision that isn't obvious from the code alone. If your explanation needs more than one line, you're probably reaching for the wrong tool (more on multi-line comments next).
One important habit: put the comment above the line it describes, not crammed at the far right end of a long line of code. Comments placed at the end of a line — called inline comments — are fine for very short labels, but if the comment is longer than about 30 characters it gets hard to read. Your future self will thank you for keeping things clean.
Notice in the example below that we don't comment every single line. We only comment where the logic needs explanation. Over-commenting is its own kind of noise — if the code already tells the story clearly, a comment just repeats it.
public class TemperatureConverter { public static void main(String[] args) { double celsius = 100.0; // 32 is the freezing point offset and 1.8 is the ratio between // the Fahrenheit and Celsius degree sizes double fahrenheit = (celsius * 1.8) + 32; // Print the result with a clear label so the output makes sense System.out.println(celsius + "°C is equal to " + fahrenheit + "°F"); int secondsInADay = 86400; // 60 seconds × 60 minutes × 24 hours System.out.println("There are " + secondsInADay + " seconds in a day."); } }
There are 86400 seconds in a day.
Multi-Line Comments — When One Line Isn't Enough
Sometimes you need more space — to explain a whole block of logic, describe the context of a method, or temporarily disable a chunk of code while debugging. That's what multi-line comments are for. They start with / and end with /, and everything in between is ignored by Java, whether it's two lines or two hundred.
A very common use case is 'commenting out' code during development. Say you wrote a calculation two different ways and you want to test one while keeping the other around. Wrap the one you're not testing in / ... / and Java pretends it doesn't exist. Just remember to clean this up before you commit your code — commented-out code that ships to production is a red flag in code reviews.
Another solid use for multi-line comments is a block at the top of a file or a complex method explaining what the code is trying to achieve overall. Think of it like the introduction paragraph of an essay — give the reader the big picture before they dive into the details.
One style note: many Java developers decorate multi-line comments with a leading asterisk on each line (the * pattern you see in the example). Java doesn't require this — those asterisks are just part of the text being ignored. But it's a widely accepted convention that makes the comment boundaries visually obvious.
public class CircleCalculator { /* * This program calculates the area and circumference of a circle. * Formula for area: PI × radius² * Formula for circumference: 2 × PI × radius * * We use Math.PI instead of hardcoding 3.14 because Math.PI gives us * the most precise value Java can store — 3.141592653589793. * Hardcoding 3.14 introduces small rounding errors that compound * in scientific or financial calculations. */ public static void main(String[] args) { double radius = 7.5; double area = Math.PI * radius * radius; double circumference = 2 * Math.PI * radius; System.out.println("Radius : " + radius + " cm"); System.out.println("Area : " + area + " cm²"); System.out.println("Circumference : " + circumference + " cm"); /* * The lines below were an alternative approach using * Math.pow() for the radius squared — kept here for reference * while we benchmark both approaches. * * double areaPowVersion = Math.PI * Math.pow(radius, 2); * System.out.println("Area (pow version): " + areaPowVersion); */ } }
Area : 176.71458676442586 cm²
Circumference : 47.12388980384689 cm
Javadoc Comments — The Professional Documentation Standard
Javadoc comments are the third type, and they're in a league of their own. They look like multi-line comments but start with /** (two asterisks) instead of one. Java's built-in documentation tool — called Javadoc — reads these special comments and automatically generates a professional HTML documentation website from them. This is exactly how the official Java documentation at docs.oracle.com was created.
You write Javadoc comments directly above a class, a method, or a variable you want to document. Inside them you use special tags that start with @ to describe specific things: @param documents a parameter the method accepts, @return describes what the method gives back, and @author records who wrote it.
Here's the key insight beginners miss: Javadoc comments aren't just for open-source libraries or huge enterprise projects. If you're writing a method that another developer (or future you) will call, a Javadoc comment means your IDE will show that documentation as a tooltip the instant someone types your method name. IntelliJ, Eclipse, VS Code — they all do this automatically. It's one of the highest-leverage habits you can build early.
For now at the beginner level, focus on documenting your public methods — the ones other code will call. Don't stress about documenting every private helper method until you have the habit down.
/** * Represents a simple bank account with basic deposit and withdrawal operations. * * <p>This class is intended for learning purposes and does not handle * concurrent access or persistent storage.</p> * * @author Alex Rivera * @version 1.0 */ public class BankAccount { /** The name of the account holder. Cannot be null or empty. */ private String ownerName; /** The current balance in the account, stored in dollars. */ private double balance; /** * Creates a new BankAccount with an initial balance. * * @param ownerName the full name of the account holder * @param initialBalance the starting balance in dollars; must be >= 0 */ public BankAccount(String ownerName, double initialBalance) { this.ownerName = ownerName; this.balance = initialBalance; } /** * Deposits a positive amount into the account. * * <p>If the deposit amount is zero or negative, the operation is * ignored and the balance remains unchanged.</p> * * @param amount the amount to deposit in dollars */ public void deposit(double amount) { if (amount > 0) { balance += amount; } } /** * Returns the current account balance. * * @return the current balance in dollars as a double */ public double getBalance() { return balance; } public static void main(String[] args) { // Create a new account for our test user with a $500 starting balance BankAccount account = new BankAccount("Maria Chen", 500.00); account.deposit(250.00); // Maria receives her paycheck portion System.out.println("Account owner : " + account.ownerName); System.out.println("Current balance: $" + account.getBalance()); } }
Current balance: $750.0
| Feature / Aspect | Single-Line `//` | Multi-Line `/* */` | Javadoc `/** */` |
|---|---|---|---|
| Syntax to open | // | /* | /** |
| Syntax to close | End of line (automatic) | */ | */ |
| Spans multiple lines? | No — one line only | Yes — unlimited lines | Yes — unlimited lines |
| Processed by Javadoc tool? | No | No | Yes |
| Can be nested? | Yes — `//` inside `/* */` | No — cannot nest `/* */` | No — cannot nest |
| Best used for | Quick inline explanations | Block explanations, disabling code | Public API documentation |
| IDE tooltip support? | No | No | Yes — shows on hover |
| Ignored by Java compiler? | Yes | Yes | Yes (content only) |
🎯 Key Takeaways
- Java has three comment types:
//for single-line,/ /for multi-line, and/* /for Javadoc — each with a distinct purpose, not just stylistic preference. - The Java compiler ignores all comment content entirely — but the Javadoc tool reads
/* /comments to generate browsable HTML documentation and power IDE tooltips. - Comment the WHY, not the WHAT — a comment that restates what the code already shows is noise; a comment that explains the reasoning behind a decision is gold.
- You cannot nest
/ /multi-line comments — attempting it causes a compile error. Use//per-line comments or your IDE's block-comment shortcut as the safe alternative.
⚠ Common Mistakes to Avoid
- ✕Mistake 1: Trying to nest multi-line comments — Writing
/ / inner comment / outer still going /causes a compile error because Java closes the comment at the first/it finds, leavingouter still going /as invalid code. Fix it by using//single-line comments inside a multi-line block, or use your IDE's line-comment shortcut (Ctrl+/ or Cmd+/) which prefixes each line with//instead. - ✕Mistake 2: Commenting WHAT the code does instead of WHY — Writing
// multiply radius by radiusaboveradius * radiusis pure noise that doubles the reading effort with zero benefit. A reader can see the multiplication — they can't see your reasoning. Replace it with something like// using radius² because the area formula requires squaring, not doubling. Always ask yourself: 'would someone reading this code already know this from the code alone?' If yes, delete the comment. - ✕Mistake 3: Leaving dead commented-out code in production commits — Blocks of
/ old code here /committed to a shared codebase confuse teammates, clutter diffs, and suggest you don't trust version control to preserve history. The fix: if you want to keep old code for reference, commit it to git with a clear commit message, then delete it. That's exactly what version control is for. Commented-out code in a pull request is one of the most common beginner code-review comments you'll receive.
Interview Questions on This Topic
- QWhat are the three types of comments in Java, and what is the key difference between a multi-line comment and a Javadoc comment?
- QDoes the Java compiler read comments? If not, what tool does read Javadoc comments and what does it produce?
- QCan you nest multi-line comments in Java? What happens if you try, and how would you work around the limitation?
Frequently Asked Questions
Do Java comments affect program performance or file size?
No. The Java compiler strips all comments before turning your code into bytecode. The compiled .class file contains zero trace of your comments, so they have absolutely no impact on runtime performance or the size of your deployed application.
When should I use Javadoc comments vs regular comments?
Use Javadoc (/* /) for any public class, method, or field that other developers will interact with — this is what generates IDE tooltips and official API docs. Use regular comments (// or / /) for internal implementation notes that explain your reasoning within a method body. A good rule of thumb: Javadoc faces outward toward users of your code; regular comments face inward toward maintainers of your code.
Is it bad practice to use comments to disable code temporarily?
Commenting out code is fine as a short-term debugging technique on your local machine. The problem is committing that commented-out code to a shared repository or leaving it there long-term. It signals to teammates that you either don't trust version control or forgot to clean up. Delete it and rely on git history to recover old code if you ever need it — that's a habit that earns serious respect in professional teams.
Written and reviewed by senior developers with real-world experience across enterprise, startup and open-source projects. Every article on TheCodeForge is written to be clear, accurate and genuinely useful — not just SEO filler.