Основные принципы Объектно-Ориентированного Программирования / программирование :: профессиональный юмор :: ООП :: geek (Прикольные гаджеты. Научный, инженерный и айтишный юмор)

geek ООП программирование профессиональный юмор 

Основные принципы Объектно-Ориентированного Программирования

Абстракция
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
Подробнее
Абстракция 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,Прикольные гаджеты. Научный, инженерный и айтишный юмор,ООП,программирование,профессиональный юмор
Еще на тему
Развернуть
Где ж ты со своим светочем был пять дней назад, а?
Это жиза привыкай
KonaKona KonaKona 11.10.201522:32 ответить ссылка 3.4
Сперва подумал что это MyExcelDays, потом присмотрелсяприсмотрелся и пригрустил :(
Приуныл же!
Та ну блять, естественно, вот эти милипиздрические схемки на ларек дяди васи, где он один и у него из вычислительных приборов только счеты и то с трудом уместятся.
А отслеживать и оптимизировать никто не будет, это ж жиза.
У тебя просто тимлида нормального не было =D
*плак-плак* даааааа
а ещё 100500 не сторонних библиотек от которых проёбаны исходники, и из документации только изредка встречающиеся комментарии к используемым методам
CriMsoN CriMsoN 11.10.201522:40 ответить ссылка 4.4
да-да, только хотел написать " и кстати мало библиотек"
Все правильно.
Первые четыре пункта это принципы быстрого достижения последнего результата.
А ещё бывает, что именно ты всё это и наворотил...
Segura Segura 11.10.201522:44 ответить ссылка 2.7
почему бывает, чаще всего именно я всё это и делаю в своих домашних прикалюхах... если больше месяца к коду не притрагивался, то можно считать код потерянным, т.к. хуйчёвспомниш из всего этого дерьма
НО ЭТО ВСЁ-РАВНО НЕ ПОВОД КОММЕНТИРОВАТЬ КОД — НАХУЙ БУДУЩЕГО МЕНЯ!
ебстественно, будущий я меня не отпиздит... а вот на работе приходится сдерживаться, хуйзнает, вдруг пока я ещё буду там работать, наймут какова бугая нам в помощь, а он возьми и залезь в мой код, потом оглядываться по сторонам в страхе что щас кулак прилетит
Кстати клёвая идея! Вангую появление произведения в жанре цибербанкъ где штрейкбрехеры будущего будут жестоко пиздить программёров за отстутсвие комментариев, но те всё-равно не будут коментить код, съезжая на "вива ля резистансЪ!".
:)
Предлагаю расширение сюжета - программеры из будущего путешествуют в прошлое, чтобы отпиздить нынешних программеров.
Ну так давно ведь известный принцип : "пиши код так, будто сопровождать его будет склонный к насилию псих, который знает, где ты живешь".
Хороший код в комментариях не нуждается, так то.
Rokov Rokov 12.10.201506:23 ответить ссылка 0.0
Люди путают документацию и комментарии
16... тысяч... строк... не документированного кода... О_О
Я уже после 100 (строк) плохо ориентироваться в своих каракулях начинаю.
MASTAR MASTAR 11.10.201522:47 ответить ссылка 1.8
Даже если с комментариями?
У меня обычно так:

//функция передачи данных
//принимает байтовый срез передаваемых данных
//возвращает результат передачи
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
}
Cobold Cobold 11.10.201522:58 ответить ссылка 4.6
Эх, и смешно, и грустно.
Фи, комментарии на русском.
Spring Spring 11.10.201523:06 ответить ссылка -1.1
Глянь на досуге какой-нибудь арабский проект, посмеёшься
Cobold Cobold 11.10.201523:15 ответить ссылка 0.9
Там каждую строчку призыв к Джихаду?
скорее "Аллах всемогущий, надеюсь, гурии встретят меня даже если я не распутаю этого адского объектного осьминога"
ddr454 ddr454 11.10.201523:34 ответить ссылка 2.2
Вот тебе пара арабских проектов, где смеяться?
https://github.com/NouranMahmoud/markdown-arabic
https://github.com/ahmadajmi/BloodDonation

Комментарии на английском - стандарт в программировании. За русские комментарии (которые не дублируют английские) в аду сажают в особо горячий котел.
Spring Spring 11.10.201523:28 ответить ссылка 0.9
Воу, воу. Да я и не спорю. Я ж не из рабочего проекта сюда кусок кода скинул.
Видел исходники какого-то проекта с комментами справа налево на арабском - смотрелось дико. Редкость, к счастью.
Cobold Cobold 11.10.201523:32 ответить ссылка 0.3
Тогда желаю поменьше видеть таких проектов, и побольше с хорошей документацией =)
Spring Spring 11.10.201523:41 ответить ссылка 0.2
У меня от твоего ника Кайл Катарн с обрыва свалился.
А все потому что абсорб качать надо!
Spring Spring 12.10.201510:37 ответить ссылка 0.0
Никогда не качал, лол. Чтобы можно было блокировать толчки и притягивания достаточно иметь не меньший уровень force push/pull, чем противник, ЕМНИП. Поэтому я всегда вкачивал боевые навыки и, опционально, восстановление, а против толчков полагался на блок.
Кстати, что там с порталами? Есть еще где в JA+ побегать?
На жаплюсе только паблик с админами свжка, ну ты понел. Более-менее адекватные сидят вечерами на базе.
Spring Spring 12.10.201511:15 ответить ссылка 0.0
А что делать за названия функций транслитом?
Сажать на кол, затем вешать, а останки разрывать, привязав конечности к четырём лошадям.
dibroo dibroo 12.10.201515:05 ответить ссылка 0.1
Как категорично.

Российская компания, с российским менеджментом, российскими программистами, делает продукт для Российского рынка.
Комментарии на английском?
Ради гипотетического случая, вдруг к разработке будут привлечены не русскоязычные кадры?
Дороговато.
//tipichniy kommentariy na angliyskom v russkoi kompanii
Такая компания бывает только сферической и в вакууме. На деле же в большинстве более-менее крупных компаниях обязательно бывают моменты, когда привлекаются иностранные аутсорсеры. Далее, закономерный этап для любой компании (за исключением разве что всяких оборонных предприятий) - это выход на иностранный рынок. Просто потому, что он больше российского. А тогда русскоязычные комментарии сильно аукнутся.
Spring Spring 12.10.201509:44 ответить ссылка 0.0
У нас на работе есть класс подсчета объёмов по счетчикам, он состоит из 10к строк, и писали его 10 лет, выглядит это как помойное ведро, НИКТО НЕ ЗНАЕТ КАК ОНО РАБОТАЕТ, и тут выясняется что оно работает неверно в определенных случаях, искать в этом, то самое место такая залупедрень...
И иногда эти 16к строк в одном файле.
Abbath Abbath 12.10.201501:11 ответить ссылка 0.2
Как-то лет семь назад, участвовал в доработке одного проекта. Там один из файлов был около 70 тысяч строк кода. Это было ядро системы разработанное основателем, лет за 10 до того. Весь остальной код в ~600 файлах был лишь обвязкой для этого ядра. Мне слава богу ничего в этом файле, за год работы, менять не пришлось.
иногда эти 16к строк в одной строке
как раз в тему: http://habrahabr.ru/company/friifond/blog/268063
undersun undersun 11.10.201522:57 ответить ссылка 1.4
Я не могу описать весь спектр эмоций
О, мы так над ппервогодками прикалываемся. Так сказать родной метод. Привет из Эллады.
16 тысяч строк это ещё мало
hinst hinst 11.10.201523:14 ответить ссылка 0.6
Пишущих код без комментов надо насиловать анально, причём объём дилдо подбирать в прямой пропорцией с количеством недокументированного/некомментированного кода. Фух, отпустило)
Учитывая что это за люди, так ты их только поощришь.
Хммм... Да, возможно:)
Кстати, похоже, мой коммент разворошил быдлокодерское гнездо)
Код должен быть самодокументированным, в первую очередь. Каждый коммент - это оправдание непонятному куску программы
Cobold Cobold 11.10.201523:25 ответить ссылка 5.2
В некоторых местах комент требуется для объяснения почему именно так а не эдак. Так что ваш комент пустоват, комментировать или нет, ответ да, но лишь там где это действительно необходимо.
Совершенно верно. И там, где код непонятен, нужно писать коммент... или рефакторить. По желанию автора.
Cobold Cobold 11.10.201523:34 ответить ссылка -0.1
Аааа, все в машину, гений программирования в треде!
Знаешь, не стоит пытаться так умничать. Даже если ты свято уверен в непогрешимости своего кода, не факт, что тебе не придётся разбирать код такого же "самодокументированного" умника- тогда твоя генияльность прилетит тебе же по роже.
Нет, мне по роже прилетит чужая "гениальность".
Комменты нужны там, где нет времени/сил/желания делать наглядно. Такое случается.
Cobold Cobold 12.10.201500:45 ответить ссылка 0.8
Да нет, твоя же- ибо ты тоже участвуешь в распостранении этого мнения.
А ты не согласен, что код *должен* быть самодокументированным?
Надо же к чему-то стремиться по мере своего скилла и доступного времени.
И я повторюсь: понятный код в комментировании не нуждается. Если ты против... ну, это было бы странно
Cobold Cobold 12.10.201507:45 ответить ссылка -0.1
Я не знаю, кто и где вбивает эту чушь вам в головы, что вы в неё свято верите. Да так свято, что готовы порвать любого, посягнувшего на священную корову. Во-первых, начнём с того, что если речь идёт не о твоей домашней поделке- то твой код может понадобится отредактировать другому человеку. И далеко не факт, что то, что тебе кажется абсолютно очевидным, для него не будет выглядеть какой-то хернёй. Далее- понятный и хороший код очень часто- разные вещи. В третьих, вопреки мнению гениев, в IDE вылавливается далеко не всё и не всегда, да и его использование не везде возможно. Ну и как тебе было бы читать тысяч двадцать строк понятного кода, чтобы отловить некую мелочь в некоей функции, которая, при наличии комментов, была бы выловлена гораздо быстрее? Суть: комменты не просто так придумали и они не просто так используются.
Я не знаю, кто и где вбивает эту чушь вам в головы, что вы в неё свято верите. Да так свято, что готовый порвать любого, посягнувшего на священную корову. Во-первых, начнём с того, что если речь идёт не о твоей домашней поделке, то писать его нужно для людей, а не гнаться за супер-эффективностью, городя малопонятные конструкции, требующие комментариев о том, как это работает. Допускать ситуацию, когда в одном файле накапливается 20000 строк кода, нельзя. Допускать ситуацию, когда функция делает не то, что ожидаешь от неё по названию - нельзя. Допускать ситуацию, когда содержимое переменной не соответствует её названию (и при этом переменная живёт дольше десятка строк кода) - нельзя. Понятный код - это и есть хороший код. Если тебе нужно оптимизировать высоконагруженное место, написав непонятный код, то изолируй его от остального кода и покрой таким количеством комментариев, каким пожелаешь. В остальных частях проекта такое обилие будет просто никому не нужным мусором (но драгоценное время разработки ты на них потратишь). Иногда бизнес-логика достаточно запутана, и требует пояснения комментариями, но в этом случае комментарии должны только пояснять, зачем мы делаем именно так, а не иначе.

Всё вышенаписанное справедливо при разработке прикладных приложений с использованием современных 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)
Этот код не является самодокументируемым.
А ты, видимо, и читать не умеешь
"пример того, как комментарии облегчают жизнь"
В данном случае два коммента экономят кучу времени оператору.
Я тебе говорю, что этот код нуждается в комментариях, потому что не является самодокументированным. Не знаю, что это за язык, поэтому не могу судить - написано убого, или язык такой примитивный.
Или язык отличный, и написано неплохо, только кое-кто не может взглянуть дальше своего ноcа?
gcode же.
Hellsy Hellsy 12.10.201510:12 ответить ссылка 0.2
Верно, только через тире.
Отлично! Язык, созданный полвека назад, ну просто отличнейшая демонстрация для "несостоятельности" современных подходов к разработке приложений. Сколько программистов в наши дни сталкивается с подобными языками на практике? 5 из 100? 1 из 100? Подходы, которые работают для таких языков, не подходят для современных высокоуровневых языков программирования, обладающих куда большей человеко-ориентированностью. Как я и сказал выше, ты зациклился на своём специфичном опыте, похоже.
Ага. Но это не совсем честно. Все-таки g-code - это низкоуровневый язык. А на низкоуровневых без комментариев вообще никак. Оппонент же имеет в виду высокоуровневые языки программирования, на которых можно создавать мнемоничесикие имена для функций и переменных так, что, типа, все само собой будет понятно. И он в чем-то прав - в мелких поделках это вполне работает. Но он не понимает, что когда программа разрастается, то возникает необходимость постоянно прыгать между классами и документацией в процессе чтения кода, чтобы понимать, что происходит и это утомительно, неэффективно, и часто ведет к серьезным скрытым ошибкам, которые успешно пройдут все тесты и просочатся в релиз.
Hellsy Hellsy 12.10.201510:46 ответить ссылка 0.0
Я работал с достаточно крупными проектами, поэтому говорю на основе своего практического опыта. С самого первого своего комментария я чётко указал, какие комментарии имеет смысл делать, а какие - нет. У меня никогда не возникало серьёзных проблем с самодокументируемым кодом, написанным с таким минимальным набором комментариев.

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

Разумеется, если проект спроектирован так себе, то и потребность в комментариях повышается, но я уже озвучил выше тезис - "если твой код нуждается в комментариях - он говно".
Ко всяким интерфейсам и классам типа ICommentRepository, CommentRepository с методами CommentReadModel GetCommentById(int Id) писать полные комменты это отличный способ бездарно тратить своё рабочее время.
Ну да, а потом выясняется, что Id - начинается с 100000, потому что 0-99999 - зарезервированные значения, что GetCommentById - читает запись из СУБД, а для быстрого чтения из memcached тебе нужно вызвать GetMemCachedCommentById, который, кстати, еще и отличается от первого возвращаемой структурой. Что для чтения ветки комментов тебе лучше воспользоваться функцией getCommentsByNodeId, а не 5000 раз дрочить СУБД/memcached. А если чтение не удалось по какой-то причине, то номер ошибки придется искать по всему коду.
Hellsy Hellsy 12.10.201508:50 ответить ссылка 0.0
> что Id - начинается с 100000,
В методе должна быть проверка граничных значений, если это играет роль.

>значения, что GetCommentById - читает запись из СУБД, а для быстрого чтения из memcached тебе нужно вызвать GetMemCachedCommentById,
Я выше сказал, публичные методы должны сопровождаться комментариями-пояснениями их назначения. А вот полные коменты для них писать - действительно пустая трата времени.

>Что для чтения ветки комментов тебе лучше воспользоваться функцией getCommentsByNodeId
То же самое.
barokko barokko 12.10.201509:39 ответить ссылка -0.1
> В методе должна быть проверка граничных значений, если это играет роль.

И комментарий, почему эта проверка существует.

> полные коменты для них писать

Тогда непонятно, что ты называешь "полными комментами" - пятистраничное сочиние? У каждого метода должны быть кратко описаны передаваемые переменные, возвращаемые данные. Если возвращаемые данные специфичны для метода (типа кода ошибки), то должны быть описаны и они тоже. Если есть хоть какие-то нюансы - они должны тоже быть описаны.

Пример такого нюанса из модуля авторизации по OAuth у разных провайдеров:

# В conf лежат:
# client_id - номер приложения mail.ru
# redirect_uri - адрес возврата, должен совпадать с таким же при запросе.
# secret_key - секретный ключ
# По документации нужно использовать private_key, но это же mail.ru, поэтому - secret_key.

sub auth_process {...
Hellsy Hellsy 12.10.201510:04 ответить ссылка 0.0
> Тогда непонятно, что ты называешь "полными комментами"
Допустим, если у метода совершенно типовой и очевидный набор параметров, его нет смысла комментировать. Если есть подвдные камни или неочевидности - тогда пожалуйста.

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


В прошлом своём проекте, не слишком большом (3 месяца разработки), я написал
1) четыре комментария, поясняющих достаточно костыльный код, который позволял использовать инъекцию зависимостей в бэкграунде в полной мере.
2) описание скрытого от глаз способа передавать во вью-модели некоторые типовые данные.
3) пара-тройка комментариев, рассказывающих, почему мы обращаемся к S3 именно таким образом и шлём именно такие метаданные.
4) описание полей классов-моделей данных.


Всё! больше в проекте комментировать решительно нечего (даже далеко не все методы сервисов нуждались в комментариях).

Потому что я не понимаю, зачем комментировать код вида
BackgroundJob.Enqueue(x => x.Perform(userId));
*код немножко порезался реактором... ну фиг с ним.
Больше комментировать нечего по твоему мнению или по мнению коллег?

В общем-то, все приходит с опытом. Как поработаешь в команде над проектом, которому больше пяти лет - начнешь ценить комментарии и жесткое соблюдение соглашений по коду. Потому что у каждого человека свои представления об очевидном, основанные на знаниях. А потом писать комментарии становится привычкой настолько, что я даже сам для себя в мелких программках пишу массу комментариев. И это отлично окупается - даже через пару лет код выглядит знакомым и легко читается.
Hellsy Hellsy 12.10.201511:15 ответить ссылка -1.5
> Больше комментировать нечего по твоему мнению или по мнению коллег?
Я передал проект на поддержку другому программисту вместе с сопроводительной запиской, в которой рассказал об общей архитектуре, используемых библиотеках и конфиг-файле. Потом последил за его комитами - всё ок. Никаких особых вопросов он не задавал по коду, только по ТЗ.

>Как поработаешь в команде над проектом, которому больше пяти лет
Одному из наших крупных (200+ таблиц в БД) проектов больше 10 лет, он до сих пор на .NET 2.0, так что опыт у меня есть.
Это один из сорока почти одинаковых репозиториев в DAL-слое, зарезервированных значений нет, наличие или отсутствие кеширования определяется при инициализации di-контейнера. И каждый раз писать, что Id - Id комменария, а returns - комментарий с заданным Id это бред. Но если херачить говнокод с кучей подводных камней - о них надо указывать, спору нет. Но лучше писать вменяемый код.
> "из сорока почти одинаковых репозиториев"

Сорок почти одинаковых? Так бы сразу и сказали. Разумеется, ни один последователь индусской религии копипаста никогда не поймет необходимости писать комментарии к коду и коммитам или соблюдать соглашения по коду.
Hellsy Hellsy 12.10.201514:10 ответить ссылка 0.0
Тебе, видимо, не доводилось работать со сколько-то крупными enterprise проектами. Много доменных объектов из различающихся предметных областей, которые достаются из БД или другого хранилища униформным образом. А разные доменные области -> разные проекты и репозитории. Это вполне реальный пример. И никакого копипаста между ними очевидно нет, методы, скажем, GetCommentById(int id) и GetOfferById(int id) каждый по 5 строк не будут являться копипастом друг друга.
По поводу соглашений по коду: у нас на текущем месте работы есть соглашение по возможности писать самодокументирующийся код, чтобы как можно реже была необходимость писать комментарии (не относится к публичным API и самым ядровым методам) и это соглашение вполне применяется. При чём здесь месседжи к коммитам, которые ты упомянул, мне вообще не понятно, про них речь не шла до этого даже.
Почему же, доводилось. Потому и говорю, сперва один "индус" своим любимым методом наплодит 100500 одинаковых классов, затем половину функционала реализует где-то снаружи любимым индусским методом - проверкой имени класса. Комментировать, ессно, ничего не будет - все же и так понятно, а если кому непонятно, то пусть лучше старается. Через пару лет получается что-то, типа показанного на картинке.

Что же до конкретно твоего примера, то куда проще было бы что-то типа comment.getById(), offer.getById(). "Наследование" и "интерфейсы" - слышал о таких концепциях ООП, позволяющих радикально уменьшить количество повторений в коде? А следующим шагом по упрощению было бы создание абстрактных схем. Но я понимаю - зачем такие сложности, когда можно просто жмакнуть в кнопку "Создать новый класс" и написать очередной набор функций из пяти строк каждая. А потом пусть те, кому достанется это счастье и долбятся с ним как хотят :-)
Hellsy Hellsy 12.10.201515:13 ответить ссылка 0.0
Ну GetById это упрощенный пример, не одним же CRUD'ом (если только круд, то выносить вверх надо, спора нет). Методы могут быть разные, хоть и похожие, в BaseRepository их не положишь. Какое отношение "реализует где-то снаружи любимым индусским методом - проверкой имени класса" имеет к приведенному мной примеру, вообще не ясно. Надоело уже, не жалко своё время и деньги работодателя - пиши не несущие смысловой нагрузки комменты, к прямо-таки деградации кода это не приведёт.
Вот в этом-то корень проблемы - в определении, какие комменты несут смысловую нагрузку, а какие нет.
Да, коммент типа "i++; // увеличим на 1", - не слишком нужен. Но я вот, например, с легкостью читаю регулярные выражения, у меня большая практика по ним, а кто-то тупит даже на элементарных. Так что, я лучше прокомментирую. Не факт, что я сам буду через год помнить типа поля в СУБД, так что, если это актуально, то я оставлю комментарий типа "40 chars max". Или вот как-то мне попалась звуковая библиотека. Я убил целый час, пока разобрался, что в аудиопотоке все каналы идут вперемешку, но весьма хитрым способом. Наверняка это было очевидно для тех, кто в теме, а я оставил комментарий-подсказку тем, кому придется разбираться с этим после меня. И таких неочевидных вещей довольно много: внешние библиотеки, всплывающие события с весьма ограниченной областью видимости, управление железом. А уж когда начинается разделение клиент-сервер или даже клиент-сервер-база данных, то там вообще приходится комментировать каждый шаг. Потому что для человека, специализирующегося на другом твой код - темный лес.
Hellsy Hellsy 12.10.201517:55 ответить ссылка 0.0
Комментарии должны идти максимум к публичным полям/методам (чтобы интеллектуальный ввод подхватывал и вообще). Комментарии внутри блока кода обычно нужны только если пишешь какой-то костыль.
А потом кто-то открывает твой код и сидит часами, выискивая, где же в нём некая функция. Или ты гений кодинга?
про IDE слышал? Функция часами выискивать...
Слышал. А про то, что не всегда это применимо в реальной жизни, ещё и видел лично.
IDE не применима в реальной жизни? Это как? В тот самый случай, один на миллион, когда ты остаёшься наедине с кодом, компилятором и блокнотом? Вот ради этих случаев ты предлагаешь удлинять в полтора раза код комментариями от капитана очевидность?
Выше почитай коммент от Hellsy и мой с примером кода. Лишний раз разжёвывать мне лень.
После такого ультимативного заявление нужно привести пример своего кода. Или просто так балаболишь?
Заявление - это идеал, к которому, по моему скромному, должен стремиться каждый.
А свои печальные реалии я уже сверху привёл.
Cobold Cobold 12.10.201507:17 ответить ссылка -0.1
Судя по минусам, которые мне накидали, тут куча гениев программирования. Неясно, правда, почему их до сих пор разные майкрософты с адобами с руками не оторвали- стесняются к таким светилам обращаться, наверное.
Из всех вас троих наиболее верную позицию высказал только Hellsy.

Хотя - почему верную? Люди вон кодят говно, ничего не комментируя, и живут себе спокойно. Скорее эта позиция наиболее человечная, выражающее уважение к коллегам.
Код должен быть самодокументированым, но и комментарии должны быть.
Hellsy Hellsy 12.10.201508:42 ответить ссылка 0.6
//самая важная функция в этой либе, вам понравитЪся
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());
}
видал как-то в местном Кекс-шопе елдак, который был больше моей сжатой в кулак руки по локоть... в принципе, для первого раза - неплохо. Для рецедива, скорее всего, подойдёт калёная булава, приделанная к суровому электрогайковёрту(мощнее любого шуруповёрта раза в 2-4)
ddr454 ddr454 11.10.201523:39 ответить ссылка 0.0
ХУЯК, ХУЯК АРХИТЕКТУРА ПРИЛОЖЕНИЯ
NOT REALLY3 Л committee - and took at the mtssm ended up with
Khanon Khanon 11.10.201523:37 ответить ссылка 4.5
Я за небольшие 6 лет опыта увидел уже столько кода без комментов и немало поработал с обфусцированным кодом, так что каждый такой код для меня наоборот это вызов. Мотивирует неплохо.
horuszp horuszp 11.10.201523:47 ответить ссылка 0.3
Что же я посмотрел только что, что же! Господи, пусть это будет фейк, прошу
Veanak Veanak 12.10.201504:13 ответить ссылка 0.1
Инкостыляция, Поликостылизм и костылирование.

П.С. ООП не так плохо когда ты прочитал хотя бы пару книжек и видел примеры хорошей архитектуры, а то у одних паттерны и солид головного мозга, у других классы == структуры, никто и не подозревает что ООП надо если не уметь, то учится готовить, и да оно не везде заходит =(
CAMOKPYT CAMOKPYT 12.10.201500:07 ответить ссылка 1.1
Ну, в С++ класс отличается от структуры только модификатором доступа по умолчанию.
raikin raikin 12.10.201500:40 ответить ссылка -0.1
Перевод не вполне верный.
Я не минусовал никого в этом треде, потому что тут почти все комменты - чья-то жизненная боль.
Недокументированный код - часть этой боли. И разве ты не согласен с тем, что код *должен* быть самодокументированным, насколько этому сопутствует скилл и доступное время?
А говнокожу я или нет - не мне судить. Свой код весь прекрасен.
Cobold Cobold 12.10.201507:41 ответить ссылка 0.1
А когда туда добавляются всплывающие события с уникальным названием типа "ERROR" или "SUCCESS", которые неизвестно кто и неизвестно где получает, а большая часть переменных оказывается геттерами/сеттерами с кучей колбэков - вот тогда хочется схватить топор с пожарного щита и тщательной побеседовать с авторами кода.
Hellsy Hellsy 12.10.201508:56 ответить ссылка 0.0
А что мешает еженедельно уделять время рефакторингу кода? ах да...лень...
Foli Foli 12.10.201509:47 ответить ссылка 0.1
Во-первых, дедлайны. А во-вторых, рефакторинг без профилирования - разновидность онанизма. Узкие места, чаще всего, неизвестны заранее.
Hellsy Hellsy 12.10.201510:08 ответить ссылка -0.5
Рефакторинг обычно не связан с оптимизацией приложения.
Только зарегистрированные и активированные пользователи могут добавлять комментарии.
Похожие темы

Похожие посты
gkoberger commented on Mar 18, 2013
Owner © • ••
Okay this is awesome. I'll test it out and merge when I get home. Thanks!
v1993 commented on Dec 17, 2020	© -
Sorry for rushing this a bit, but got home yet?
подробнее»

песочница программирование geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор терпение профессиональный юмор it юмор

gkoberger commented on Mar 18, 2013 Owner © • •• Okay this is awesome. I'll test it out and merge when I get home. Thanks! v1993 commented on Dec 17, 2020 © - Sorry for rushing this a bit, but got home yet?
Newbie: So which programming language should I learn first?
Programmers: Почему?
Почему?!
^>о->Ьаг() — Почему?



— А, вот почему... Nikitoz9595 17 часов назад
У меня у одного от интро мурашки по коде бегут ?
Ответить . 11
Скрыть ответы л
Werner Warhater 16 часов назад +Nikitoz9595 Мурашки в коде это уже 'баги"
Ответить -19
•*Ä'* TehAwesome 15 часов назад
+Werner Warhater сделал мой вечер.
Ответить .
подробнее»

geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор программирование ООП баги код program песочница удалённое

Nikitoz9595 17 часов назад У меня у одного от интро мурашки по коде бегут ? Ответить . 11 Скрыть ответы л Werner Warhater 16 часов назад +Nikitoz9595 Мурашки в коде это уже 'баги" Ответить -19 •*Ä'* TehAwesome 15 часов назад +Werner Warhater сделал мой вечер. Ответить .
Жак Фреско про программирование и ООП,Science & Technology,жак фреско,программирование,ооп,мемы,переозвучка,???? Бонусы за спонсорство
https://www.youtube.com/ExtremeCode/join

???? Discrod: https://dscrd.in/extremecode_from_youtube
???? Telegram: https://t.me/extremecode_chat
???? VK: https://vk.co
подробнее»

Жак Фреско программирование geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор it-юмор видео,video ООП

Жак Фреско про программирование и ООП,Science & Technology,жак фреско,программирование,ооп,мемы,переозвучка,???? Бонусы за спонсорство https://www.youtube.com/ExtremeCode/join ???? Discrod: https://dscrd.in/extremecode_from_youtube ???? Telegram: https://t.me/extremecode_chat ???? VK: https://vk.co