Please, don't hesitate to comment.
Comments increase the overall code footprint, but that's not a problem at all, because there are many tools which minify the code before publishing to production server. They remove comments, so they do not appear in the working scripts.
The code clarity is what we should hunt for. And comments can really help to make it easier to understand.
There are various types of comments, answering different questions:
- What the code does?
- Why the code is written like that?
- Which counter-intuitive or implicit connections it has with other parts of the program?
Further in the tutorial we'll make more notes about how to write the code better, easier to read and maintain. We'll also talk more about comments.
Please note that the first type of comments ("what the code does") should be used to describe a "high-level" action, like the overall architecture, a function or a chunk of code. It's purpose is to give an overview, so a reader doesn't need to delve into the code and figure out.
Novice programmers sometimes tend to elaborate too much. Please don't. The good code is inherently readable. No need to describe what few lines do. Unless it's something hard to grasp, and *then* it's worth to consider rewriting the code at the first place rather than commenting it.