Comments: what changed
Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.
| Old | New | Line | |
|---|---|---|---|
| 1 | 1 | Go to: [[Reserved words]] \| [[Operators]] | |
| 2 | 2 | ||
| 3 | 3 | Comments are human-readable notes or other kinds of annotations to support understanding of code. They are not interpreted by the compiler and ignored when building your program. | |
| 4 | 4 | ||
| 5 | 5 | ## Block comments | |
| 6 | 6 | ||
| 7 | - | ||
| 8 | - | ||
| 9 | 7 | { | |
| 10 | 8 | ||
| 11 | - | ||
| 12 | - | ||
| 13 | - | ||
| 14 | - | ||
| 15 | 9 | } | |
| 16 | 10 | ||
| 17 | - | ||
| 18 | - | ||
| 19 | 11 | Block comments are delimited by the characters `{ }`\ | |
| 20 | 12 | ||
| 21 | - | ||
| 22 | - | ||
| 23 | 13 | (* | |
| 24 | 14 | ||
| 25 | - | ||
| 26 | - | ||
| 27 | - | ||
| 28 | - | ||
| 29 | 15 | *) | |
| 30 | 16 | ||
| 31 | - | ||
| 32 | - | ||
| 33 | 17 | or by the bigrams `(* *)`. The latter is a relict from times where computer keyboards did not necessarily have curly braces. It is *not wrong* to use the bigrams, but they are at large superseded by the use of curly braces. There is one place where the `(*` and `*)` bigrams can be useful. if you are testing code and want to "dike out" or disable certain sections by marking them as inoperative, the pieces can be surrounded by these bigrams, and it will not matter if there are and } comments inside of them. | |
| 34 | 18 | ||
| 35 | 19 | Example: | |
| 36 | 20 | ||
| 37 | 21 | ``` pascal | |
| 38 | 22 | { public declarations } | |
| 39 | 23 | ``` | |
| 40 | 24 | ||
| 41 | 25 | In Pascal block comments can be nested. However, nested block comment delimiters have to match: If a block comment starts with an opening curly brace, it can not be closed by asterisk-closing-parenthesis but has to be closed by another closing curly brace. | |
| 42 | 26 | ||
| 43 | 27 | There is a special class of comment, either beginning `{$` or `(*$`. This indicates the start of a *[[Compiler directive|compiler directive]]*, a special instruction to the ompiler about the program, but it does not actually generate instructions to be executed. | |
| 44 | 28 | ||
| 45 | 29 | ## Line comments | |
| 46 | 30 | ||
| 47 | 31 | Line comments or inline comments start with comment delimiter [[Slash|//]] and continue until the [[End of Line|end of the line]]. Example: | |
| 48 | 32 | ||
| 49 | 33 | ```delphi | |
| 50 | 34 | // This is a stupid comment | |
| 51 | 35 | ``` | |
| 52 | 36 | ||
| 53 | 37 | ## Comments as declaration hints in Lazarus IDE | |
| 54 | 38 | ||
| 55 | 39 | The Lazarus IDE can display tooltip hints when mouseovering identifiers. You can control this in Options \> Editor \> Completion and Hints. | |
| 56 | 40 | ||
| 57 | 41 | The hint shows the function or variable definition, but can also include custom descriptive text taken from comment lines directly above the declaration. | |
| 58 | 42 | ||
| 59 | - | ||
| 60 | - | ||
| 61 | - | ||
| 62 | - | ||
| 43 | + |  | |
| 63 | 44 | ||
| 64 | 45 | ## Best practice for good comments | |
| 65 | 46 | ||
| 66 | 47 | Mentioning some general tips for writing “good” comments may not be left out here, too: | |
| 67 | 48 | ||
| 68 | 49 | - Write *why* something is done. Do not write *what* is done, since that can (provided *meaningful* identifiers are in place) be determined from the code itself. It would be redundant to repeat what the code already says by itself. | |
| 69 | 50 | - Structure your comments. For example write a summary above each method definition explaining what it does and how to use it, i.e. what impact parameters have on the method's behavior. | |
| 70 | 51 | - Especially name (non-trivial) *constraints* that came from other places, that made you choose writing a particular line of code, or select a particular approach to solve the problem. | |
| 71 | 52 | - Write in *one* language throughout the whole project. De facto English is the most prevalent comment language, but especially in the context of teaching other languages are more suitable. It is important that all team members can express complex circumstances in the used language (that's easier said than done). | |
| 72 | 53 | ||
| 73 | 54 | ## See also | |
| 74 | 55 | ||
| 75 | 56 | - [[Program Structure|program structure]] | |
| 76 | 57 | - [category: compiler directives](/wiki-category/Compiler%20directives) | |
| 77 | 58 | - [§ “Comments” in the “Free Pascal reference guide”](https://www.freepascal.org/docs-html/ref/refse2.html) | |
| 78 | 59 | ||
| 79 | 60 | --- | |
| 80 | 61 | *From the Free Pascal wiki, page "Comments", as it stood on 2022-08-06 after a change by Kai Burghardt, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).* |