Основные принципы Объектно-Ориентированного Программирования
Подробнее
Абстракция BankAccount accountNo balance Robert's Account Julia’s Account A8624 A6363 $500 $800 5/3/2015 7/8/2014 Checking Checking Инкапсуляция BankAccount accountNumber balance dateOpened accountType open{) close() deposit!) withdraw!) Наследование Person name email phone changeEmail() Customer customerNumber Полиморфизм Продакшн
geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,ООП,программирование,профессиональный юмор
Еще на тему
А отслеживать и оптимизировать никто не будет, это ж жиза.
Первые четыре пункта это принципы быстрого достижения последнего результата.
:)
Я уже после 100 (строк) плохо ориентироваться в своих каракулях начинаю.
//функция передачи данных
//принимает байтовый срез передаваемых данных
//возвращает результат передачи
func sendData(data []byte) (result bool) {
result = net.send(data)
return result
}
//TODO: написать описание
func gDFUS_test(r map[string]interface{}, k []string, p bool) {
...
//сто двадцать строк сокращённого ада
//и обращений к неизвестным науке библиотекам
//без единого коммента
return true
}
https://github.com/NouranMahmoud/markdown-arabic
https://github.com/ahmadajmi/BloodDonation
Комментарии на английском - стандарт в программировании. За русские комментарии (которые не дублируют английские) в аду сажают в особо горячий котел.
Видел исходники какого-то проекта с комментами справа налево на арабском - смотрелось дико. Редкость, к счастью.
Кстати, что там с порталами? Есть еще где в JA+ побегать?
Российская компания, с российским менеджментом, российскими программистами, делает продукт для Российского рынка.
Комментарии на английском?
Ради гипотетического случая, вдруг к разработке будут привлечены не русскоязычные кадры?
Дороговато.
Знаешь, не стоит пытаться так умничать. Даже если ты свято уверен в непогрешимости своего кода, не факт, что тебе не придётся разбирать код такого же "самодокументированного" умника- тогда твоя генияльность прилетит тебе же по роже.
Комменты нужны там, где нет времени/сил/желания делать наглядно. Такое случается.
Надо же к чему-то стремиться по мере своего скилла и доступного времени.
И я повторюсь: понятный код в комментировании не нуждается. Если ты против... ну, это было бы странно
Всё вышенаписанное справедливо при разработке прикладных приложений с использованием современных IDE. Суть - "самый лучший комментарий это тот, написания которого ты смог избежать" (с)
Если твой код нуждается в комментариях, то он - говно. Иногда так бывает и ничего не поделаешь, но чаще всего вместо написания комментария нужно исправлять сам код.
Собственно, твою позицию понял, но это- позиция зазнавшегося заумничающего неуча, чей код как раз и является искомым говносм, только для него его индусятина идеальна и "самодокументирована". Я, кстати, скинул тебе две ссыли по теме, приобщайсь.
Раз
http://ruseller.com/lessons.php?id=984&rub=37
два
http://grigorievs.blogspot.ru/2010/07/blog-post.html
Если и теперь не поймёшь, то и смысла объяснять что-то дальше нету.
http://programmers.stackexchange.com/questions/51307/self-documenting-code-vs-commented-code - а это критика примера, приведённого в первой твоей ссылке. И я с критикой полностью согласен.
ему в пару требуются только комментарии вида "зачем мы это делаем".
Взаимоисключающие параграфы налицо, но хоть прогресс есть.
И я так понима, что тебе пришлось лезть аж на забугорные сайты, чтоб найти ну хоть кого-то согласного с тем, что вкоде не должно быть ни одного комментария?
Короче, поднадоело мне уже разжёвывать очевидное, так что я сваливаю.
Иди и прочитай ещё раз самый первый мой комментарий, прогрессор ты наш.
Я на русскоязычные сайты редко заглядываю - в них разве что переводы статей толковые найти можно. Сторонников - море. Написаны книги за авторством авторитетных людей (ссылка на одну их них есть в комментарии, что я кинул). Но ты типичный фанатик, который зациклился на своём, очень специфическом, опыте.
Пример того, как комментарий облегчает жизнь:
N1
G80T8
M6
G56
M01
G28G91Z0.
G0G40G90G95
X0.Y0.
S550M03
G43Z10.M08H8 (KORREKTOR. )
G81G98Z-24.R2.F0.07
/Y-102.
G80
M05
G28G91Z0.M09
M01G90
M00 (PROVER OTVERSTIE)
"пример того, как комментарии облегчают жизнь"
В данном случае два коммента экономят кучу времени оператору.
Проблемы возникают, когда код перестаёт быть самодокументируемым. Размер проекта тут не играет большой роли, т.к. в нормальном проекте отдельные модули достаточно изолированы друг от друга, чтобы можно было сосредоточится на одном, проблемном, не заглядывая в остальные.
Разумеется, если проект спроектирован так себе, то и потребность в комментариях повышается, но я уже озвучил выше тезис - "если твой код нуждается в комментариях - он говно".
В методе должна быть проверка граничных значений, если это играет роль.
>значения, что GetCommentById - читает запись из СУБД, а для быстрого чтения из memcached тебе нужно вызвать GetMemCachedCommentById,
Я выше сказал, публичные методы должны сопровождаться комментариями-пояснениями их назначения. А вот полные коменты для них писать - действительно пустая трата времени.
>Что для чтения ветки комментов тебе лучше воспользоваться функцией getCommentsByNodeId
То же самое.
И комментарий, почему эта проверка существует.
> полные коменты для них писать
Тогда непонятно, что ты называешь "полными комментами" - пятистраничное сочиние? У каждого метода должны быть кратко описаны передаваемые переменные, возвращаемые данные. Если возвращаемые данные специфичны для метода (типа кода ошибки), то должны быть описаны и они тоже. Если есть хоть какие-то нюансы - они должны тоже быть описаны.
Пример такого нюанса из модуля авторизации по OAuth у разных провайдеров:
# В conf лежат:
# client_id - номер приложения mail.ru
# redirect_uri - адрес возврата, должен совпадать с таким же при запросе.
# secret_key - секретный ключ
# По документации нужно использовать private_key, но это же mail.ru, поэтому - secret_key.
sub auth_process {...
Допустим, если у метода совершенно типовой и очевидный набор параметров, его нет смысла комментировать. Если есть подвдные камни или неочевидности - тогда пожалуйста.
Или писать комментарии внтури функции - практически всегда излишне, и говорит о том, что код так себе.
В прошлом своём проекте, не слишком большом (3 месяца разработки), я написал
1) четыре комментария, поясняющих достаточно костыльный код, который позволял использовать инъекцию зависимостей в бэкграунде в полной мере.
2) описание скрытого от глаз способа передавать во вью-модели некоторые типовые данные.
3) пара-тройка комментариев, рассказывающих, почему мы обращаемся к S3 именно таким образом и шлём именно такие метаданные.
4) описание полей классов-моделей данных.
Всё! больше в проекте комментировать решительно нечего (даже далеко не все методы сервисов нуждались в комментариях).
Потому что я не понимаю, зачем комментировать код вида
BackgroundJob.Enqueue(x => x.Perform(userId));
В общем-то, все приходит с опытом. Как поработаешь в команде над проектом, которому больше пяти лет - начнешь ценить комментарии и жесткое соблюдение соглашений по коду. Потому что у каждого человека свои представления об очевидном, основанные на знаниях. А потом писать комментарии становится привычкой настолько, что я даже сам для себя в мелких программках пишу массу комментариев. И это отлично окупается - даже через пару лет код выглядит знакомым и легко читается.
Я передал проект на поддержку другому программисту вместе с сопроводительной запиской, в которой рассказал об общей архитектуре, используемых библиотеках и конфиг-файле. Потом последил за его комитами - всё ок. Никаких особых вопросов он не задавал по коду, только по ТЗ.
>Как поработаешь в команде над проектом, которому больше пяти лет
Одному из наших крупных (200+ таблиц в БД) проектов больше 10 лет, он до сих пор на .NET 2.0, так что опыт у меня есть.
Сорок почти одинаковых? Так бы сразу и сказали. Разумеется, ни один последователь индусской религии копипаста никогда не поймет необходимости писать комментарии к коду и коммитам или соблюдать соглашения по коду.
По поводу соглашений по коду: у нас на текущем месте работы есть соглашение по возможности писать самодокументирующийся код, чтобы как можно реже была необходимость писать комментарии (не относится к публичным API и самым ядровым методам) и это соглашение вполне применяется. При чём здесь месседжи к коммитам, которые ты упомянул, мне вообще не понятно, про них речь не шла до этого даже.
Что же до конкретно твоего примера, то куда проще было бы что-то типа comment.getById(), offer.getById(). "Наследование" и "интерфейсы" - слышал о таких концепциях ООП, позволяющих радикально уменьшить количество повторений в коде? А следующим шагом по упрощению было бы создание абстрактных схем. Но я понимаю - зачем такие сложности, когда можно просто жмакнуть в кнопку "Создать новый класс" и написать очередной набор функций из пяти строк каждая. А потом пусть те, кому достанется это счастье и долбятся с ним как хотят :-)
Да, коммент типа "i++; // увеличим на 1", - не слишком нужен. Но я вот, например, с легкостью читаю регулярные выражения, у меня большая практика по ним, а кто-то тупит даже на элементарных. Так что, я лучше прокомментирую. Не факт, что я сам буду через год помнить типа поля в СУБД, так что, если это актуально, то я оставлю комментарий типа "40 chars max". Или вот как-то мне попалась звуковая библиотека. Я убил целый час, пока разобрался, что в аудиопотоке все каналы идут вперемешку, но весьма хитрым способом. Наверняка это было очевидно для тех, кто в теме, а я оставил комментарий-подсказку тем, кому придется разбираться с этим после меня. И таких неочевидных вещей довольно много: внешние библиотеки, всплывающие события с весьма ограниченной областью видимости, управление железом. А уж когда начинается разделение клиент-сервер или даже клиент-сервер-база данных, то там вообще приходится комментировать каждый шаг. Потому что для человека, специализирующегося на другом твой код - темный лес.
А свои печальные реалии я уже сверху привёл.
Хотя - почему верную? Люди вон кодят говно, ничего не комментируя, и живут себе спокойно. Скорее эта позиция наиболее человечная, выражающее уважение к коллегам.
public int a(int b, int c, int r)
{
q(b+c);//прогреваем кэш для z
if(s())//>=w(r)
{
a(c+r);//это чтобы не вылетело
}
return h(r, a, c-s());
}
П.С. ООП не так плохо когда ты прочитал хотя бы пару книжек и видел примеры хорошей архитектуры, а то у одних паттерны и солид головного мозга, у других классы == структуры, никто и не подозревает что ООП надо если не уметь, то учится готовить, и да оно не везде заходит =(
Я не минусовал никого в этом треде, потому что тут почти все комменты - чья-то жизненная боль.
Недокументированный код - часть этой боли. И разве ты не согласен с тем, что код *должен* быть самодокументированным, насколько этому сопутствует скилл и доступное время?
А говнокожу я или нет - не мне судить. Свой код весь прекрасен.