Как вы отнситесь к коментам?

Чисто статистика.

 

Когда пишу всякие лабы и прочую муть то пишу к каждой строке комменты (ну кроме всяких begin-end в паскале), если что-то для себя то без комментов да еще и "колбасой", без отступов, хотя от этого уходить стал в последнее время.

 

комментировать имеет смысл только не очевидные моменты.

 

Коментирую классы, методы, функции, и замудренные куски в коде.
Видел php код в котором каждая строка почти откоменчена это бы пздц..

 

а я не комментирую - свой кусок кода всегда распознаю как-то даже не задумываюсь об этом)) и так помню, что каждый отрывок кода реализует в каждом приложении

 

попробуй написать что то увесистое и прочитать это через пол года.

 

у майкрософта мне нравится способ комментирования:

Code:

NTSTATUS
NtMapViewOfSection(
    IN HANDLE SectionHandle,
    IN HANDLE ProcessHandle,
    IN OUT PVOID *BaseAddress,
    IN ULONG ZeroBits,
    IN ULONG CommitSize,
    IN OUT PLARGE_INTEGER SectionOffset OPTIONAL,
    IN OUT PULONG ViewSize,
    IN SECTION_INHERIT InheritDisposition,
    IN ULONG AllocationType,
    IN ULONG Protect
    )

/*++

Routine Description:

    This function maps a view in the specified subject process to
    the section object.

Arguments:

    SectionHandle - Supplies an open handle to a section object.

    ProcessHandle - Supplies an open handle to a process object.

    BaseAddress - Supplies a pointer to a variable that will receive
         the base address of the view. If the initial value
         of this argument is not null, then the view will
         be allocated starting at the specified virtual
         address rounded down to the next 64kb address
         boundary. If the initial value of this argument is
         null, then the operating system will determine
         where to allocate the view using the information
         specified by the ZeroBits argument value and the
         section allocation attributes (i.e. based and
         tiled).

    ZeroBits - Supplies the number of high order address bits that
         must be zero in the base address of the section
         view. The value of this argument must be less than
         21 and is only used when the operating system
         determines where to allocate the view (i.e. when
         BaseAddress is null).

    CommitSize - Supplies the size of the initially committed region
         of the view in bytes. This value is rounded up to
         the next host page size boundary.

    SectionOffset - Supplies the offset from the beginning of the
         section to the view in bytes. This value is
         rounded down to the next host page size boundary.

    ViewSize - Supplies a pointer to a variable that will receive
         the actual size in bytes of the view. If the value
         of this argument is zero, then a view of the
         section will be mapped starting at the specified
         section offset and continuing to the end of the
         section. Otherwise the initial value of this
         argument specifies the size of the view in bytes
         and is rounded up to the next host page size
         boundary.

    InheritDisposition - Supplies a value that specifies how the
         view is to be shared by a child process created
         with a create process operation.

        InheritDisposition Values

         ViewShare - Inherit view and share a single copy
              of the committed pages with a child process
              using the current protection value.

         ViewUnmap - Do not map the view into a child
              process.

    AllocationType - Supplies the type of allocation.

         MEM_TOP_DOWN
         MEM_DOS_LIM
         MEM_LARGE_PAGES

    Protect - Supplies the protection desired for the region of
         initially committed pages.

        Protect Values


         PAGE_NOACCESS - No access to the committed region
              of pages is allowed. An attempt to read,
              write, or execute the committed region
              results in an access violation (i.e. a GP
              fault).

         PAGE_EXECUTE - Execute access to the committed
              region of pages is allowed. An attempt to
              read or write the committed region results in
              an access violation.

         PAGE_READONLY - Read only and execute access to the
              committed region of pages is allowed. An
              attempt to write the committed region results
              in an access violation.

         PAGE_READWRITE - Read, write, and execute access to
              the region of committed pages is allowed. If
              write access to the underlying section is
              allowed, then a single copy of the pages are
              shared. Otherwise the pages are shared read
              only/copy on write.

Return Value:

    Returns the status

    TBS

--*/

{
     ...
}

очень удобно.

 

Это уже не коммент, а мануал целый )

 

есть стандарты комментирования, которые повышают читаемость кода, документируя его. испльзую некоторые из них, очень удобно.

 

что есче за стандарты?

 

phpdoc, javadoc - генераторы документации.

Вообще если для понимания кода нужны комментарии, то код нуждается в рефакторинге
А документация это отдельная тема, если ты пишешь для людей, писать ее приходится, а если я пишу для себя в комментариях в основном оставляю заметки TODO, что бы быстро ориентироваться по ним в IDE, мол "//TODO: временный костыль, переписать метод"

 

не обязательно. например ты в коде реализуешь какой то редкий алгоритм, аля алгоритм Коэна-Сазерленда. имеет смысл пояснить где что для людей, которые будут разбирать твой код.

 

Во-во, согласен по всем параграфам, поэтому кроме todo коментов в моем коде нет

 

Тот кто не пишет комментов элементарно не думает об остальных, кому через год, три, пять прийдется мониторить и изменять код.

 

ну каждую строку комментировать, это порно, ну или студенческая лаба...

 

Никто и не говорит про каждую строчку, хотя мелкомягкие так и делают и вообщем то я не против если так и останется, но суть не в этом. Комменты ускоряют понятие кода, могу выразить свою точку зрение 1 раз со стороны программиста, 2 раз со стороны человека пишущего ТЗ для фирм и разруливающий вопросы с тех. отделом.

1. Открываю проект, в котором нужно расширить функционал и видоизменить некоторые старые моменты.
Вижу комменты - радостно пробегаюсь по классу и методам глаза, читая пояснения. Общая картина составленна, остаётся найти нужно место и разобраться, что там и как.
Не вижу комментов - начинаю лихорадочно просматривать зачем каждый метод, как он реализован и действительно ли он делает, то что следует из его названия DriveAuto(); - или от великого знания английсЦкого "писатель" ошибся, а имел ввиду DrawAuto(); (реальный случай).

2. Составляю ТЗ, несу на одобрение, после чего тащу в тех. отдел и начинаем разбор полетов. Ребята из техотдела начинают меня крыть мысленно матом: "Мудила такой притащил проект 40 000+ строчек кода, так там комментов от силы 10. Теперь просматривай чуть ли не каждую строчку, исправляй, ищи и документируй. Мы бы ТЗ то мы за полторы-две недели сделали бы при хорошей документации, а так только 2 недели на мониторинг кода потратить прийдётся. Вот же гусь долбанный."

Если скрипт не на 1000 строк. Если вы пишите не только для себя. Если у вас есть хоть капелька солидарности.
Комментируйте свой код!

 

пишу там, где замороченные конструкции.
а перед функцией - что делает и какие параметры принимает, какие коды возвращает и чо они значут.

 

Только неясные моменты; заваленный код тоже не очень
А так же пометки: протестировано; нужно исправить/добавить и т.д.

 

когда пишу для себя то вообще не пишу комментарии...

по минимуму комментировал бы назначение параметров и возвращаемого значение если бы командой код писали...

 

своё не комментирую, общее на уровне типов и членов (xml комменты), и лишь изредка внутри функций/методов оставляю поясняющие комментарии.