Рекомендуемые правила оформления кода

[Пепел Феникса]

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

[Bustle]

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

[Пепел Феникса]

но при хорошем коде отнюдь не везде.
например LoadFromFile(string) не сильно нуждется в документации.
но может быть нужно разьяснение результатов(например -1 для CreateFile обязательно) или же насчет исключений.

[Utkin]

например LoadFromFile(string) не сильно нуждется в документации.

Нуждается. Вы загружаете файл, но какой? Настройки, данные, локализация? Что если Вы работаете с более чем одним файлом? Комментируют не строки программы, комментируют алгоритм выраженный в данных строках. Даже i++ нуждается в комментарии. Недостаток Вашего подхода описан Вами в посте 19.

[anyx]

Сообщение от Bustle

Табуляция 4 пробельных символа (именно пробельных символа, а не знак табуляции)

Господи, а это ещё зачем? Табуляцию табом нужно делать! Ведь у программиста в его среде разработки отображение табуляции настроено так, как ему нравится. У кого 4 пробела, а у кого-то 2 или 8. А делая отступы пробелами вы заставляете другого программиста принимать ваши правила

Сообщение от ImmortalAlexSan

1. Параметры функции именую, начиная с "p" : pParameter и т.д.
2. Внутренние переменые функций именую, начиная с "_" _Data и т.д.

Сообщение от Пепел Феникса

С++/C#
2)у параметров у методов обычно ставлю нижнее подчеркивание, но не всегда, а обычно только тогда когда конфликт с именем поля(причем для списка инициализации)

Предварять исходное имя какими-то символами не есть хорошо. По идее система типов языка должна позволять обходиться вообще без доп. символов (Haskell), но если это не так (C/C++), то доп. символы я всегда ставлю после идентификатора: String_t (тип в Си, в таком случае String = String_t*, т.к. в основном используется указатель, а не структура), width_ (параметр функции или локальная переменная в Cи/C++, если он перекрывает поле класса или параметр соответственно), filename_m (приватное поле класса)

Предварять имя плохо, т.к. помня имя вы можете не вспомнить префикс, тогда IDE вам ничем не поможет - по Ctrl+Space имя выдаётся, если вы набрали его начало, но не середину (во всех IDE, в которых я работал)

Сообщение от Пепел Феникса

С++/C#
Делфи:
2)классы как положенно с Т, предрекая имя класса префиксом
3)поля предрекаю F<имя>

Да, в дельфи никак без этого из-за нечувствительного к регистру символов компилятора

Сообщение от ImmortalAlexSan

Стив Макконел "Совершенный Код" несколько изданий.

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

[Пепел Феникса]

Нуждается. Вы загружаете файл, но какой? Настройки, данные, локализация? Что если Вы работаете с более чем одним файлом?

учитывая что я за ООП, то этот метод будет частью класса.

Недостаток Вашего подхода описан Вами в посте 19.

дык там про "пьяный" код.
и про самодокументируемый.

Даже i++ нуждается в комментарии.

перебор с комментами тоже плохо.
все зависит от того как организовать код.

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

[Alex11223]

Господи, а это ещё зачем? Табуляцию табом нужно делать!

Затем, что это холиварная тема. В любом сообществе, форуме и т.п. на тему программирования бывают холивары на тему пробелы vs табы.

Пример: http://habrahabr.ru/tag/табуляция/ (по тегам еще штук 10 тем), http://stackoverflow.com/search?q=ta...&submit=search

[Utkin]

дык там про "пьяный" код.
и про самодокументируемый.

Дык и я про тоже самое. Не важно в каком виде код был писан. Алгоритм его работы должен быть ясен всегда. При определенной методике это возможно.

[MaTBeu]

Сообщение от Utkin

1. Практически каждая строка должна иметь поясняющий комментарий (кроме совсем очевидных, вроде end или операторных скобок).

и

Сообщение от Utkin

Даже i++ нуждается в комментарии

Это глупости. Код нужно документировать, а не комментировать. Хорошая документация заменяет кучу комментариев.
А уж про комментирование каждой строки так это вообще глупости. Сразу выдает студенческий уровень знаний. А все потому что нормальный программист понимает что такое if(...), else, i++ и иже с ними.

По сабжу - использую JavaDoc, jsDoc, YUIDoc.

[Utkin]

Вы не поняли сути - описывается не i++. Описывается алгоритм.

Сразу выдает студенческий уровень знаний.

Я бы был более осторожен в оценках и навешиваемых ярлыках.