Існуючі типи коментарів:

• пояснення складного (витонченого) коду - дуже часто при вирішенні певних завдань (особливо критично важливих по швидкості роботи) не вдається уникнути використання алгоритмів, які дуже складні для розуміння - в даному випадку тільки докладний коментар дозволяє розібратися, як функціонує даний код;

• маркери - маркери зазвичай використовуються програмістами для тимчасових цілей, коли потрібно відзначити налагоджувальні команди або незакінчені фрагменти коду; коли проект завершується, маркери і, при необхідності, супутній їм код, видаляються;

• роздільники - в сучасних проектах розміри вихідних файлів можуть бути надзвичайно великими, і для того, щоб допомогти у відділенні структурних частин коду також можуть використовуватися коментарі; зазвичай в коментарях подібного типу застосовуються повторюють символи (-, =, # та ін), щоб зробити форматування більш наочним, однак в даному випадку не рекомендується використовувати символ "*";

• резюмують код коментар - цей тип коментаря пояснює, яким чином працює код і дозволяє без вникання в деталі реалізації зрозуміти алгоритм роботи; зазвичай даний коментар поміщається спочатку структурного блоку коду (модуля / класу / методу / процедури / функції і т.д.) і його значимість істотно збільшується одночасно із зростанням розмірів коду;

• опис використання коду - даний тип коментаря надає інформацію, яким чином використовувати певні змінні / процедури / функції і т.д. і зазвичай поміщається перед ними; даний тип коментаря може містити додаткову інформацію щодо особливостей функціонування коду, наприклад, можливі "побічні ефекти"

Загальні міркування по використанню коментарів можуть бути наступними:

• пишіть коментар недалеко від початку модуля для пояснення його призначення;

• пишіть коментар перед оголошенням класу;

• пишіть коментар перед оголошенням методу;

• уникайте очевидних коментарів: (i: = i + 1 / / додати до i одиницю);

• пам'ятайте, що вводить в оману коментар гірше, ніж його відсутність;

• уникайте поміщати в коментар інформацію, яка з часом може бути не вірна;

• уникайте прикрашати коментарі зірочками або іншими символами;

• для тимчасових (відсутні в релізі) коментарів використовуйте "TODO";

• намагайтеся створювати, де це має сенс, один блоковий коментар доступний для розуміння, ніж безліч розрізнених коментарів, розкиданих по коду і ускладнюють його читання; це особливо актуально при поясненні роботи складних алгоритмів - краще пояснити все один раз і відразу, ніж коментувати окремі шматки складного коду;

• коментуйте цикли, логічні умови - саме ці ділянки коду є ключовими при його вивченні;

• завжди коментуйте виправлення помилок і супроводжуючий даному процесу код;

• обов'язково коментуйте код, що впливає на зміну інтерфейсів, поведінку об'єктів і т.д. - Будь-які внутрішні зміни, які тягнуть за собою зміну роботи зі структурними одиницями коду ззовні, повинні бути закоментовані;

• коментуйте завершальний end структурних блоків програми, які не поміщаються на один екран при перегляді (наприклад, цикли, умовні перевірки, оператор case).