В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Kotlin Moscow

359 membersпожаловаться на группу
2019 August 30

AN

Alexander Nozik in Kotlin Moscow
Alexander Larin
я так понимаю, это какое-то одно из приложений к документации? вы в основной документации ссылаетесь на 34ый ли 19ый гост как стандарт оформления? и будь я потенциальным исполнителем я бы спросил, что делать если я использую в составе разрабатываемой системы какой то опенсорсный кусок, надо ли мне менять там нотацию комментариев, например?)
Там под часть требований stdlib java не подпадает
источник
21:41пожаловаться

Ⓢ

Ⓢⓔⓡⓖ in Kotlin Moscow
У меня был коллега, требовал от всех на Си++ обязательно добавлять m_ к именам полей классов. (стиль Microsoft , слава инопланетянам, они сейчас от него отказались)
источник
21:49пожаловаться

Ⓢ

Ⓢⓔⓡⓖ in Kotlin Moscow
А ещё классы начинать с буквы C, а интерфейсы с буквы I (последнее есть до сих пор)
источник
21:50пожаловаться

Ⓢ

Ⓢⓔⓡⓖ in Kotlin Moscow
Ⓢⓔⓡⓖ
Мне нравятся, хорошие требования, только они в основном хороши для новичков, чтобы понять, что можно а что нельзя
про комментарии: хорошим стилем является вообще отстуствие комментариев, точнее, написание кода программы так, чтобы всё было понятно из методов и переменных, без лишних слов на человеческом языке
источник
22:01пожаловаться

Ⓢ

Ⓢⓔⓡⓖ in Kotlin Moscow
В эпоху Agile требовать документировать всё подряд - безумство
источник
22:02пожаловаться

AN

Alexander Nozik in Kotlin Moscow
Ⓢⓔⓡⓖ
про комментарии: хорошим стилем является вообще отстуствие комментариев, точнее, написание кода программы так, чтобы всё было понятно из методов и переменных, без лишних слов на человеческом языке
Категорически не согласен. Считаю самодокументируемый код вредным мифом.
источник
22:05пожаловаться

КБ

Константин Буланов in Kotlin Moscow
Alexander Larin
я так понимаю, это какое-то одно из приложений к документации? вы в основной документации ссылаетесь на 34ый ли 19ый гост как стандарт оформления? и будь я потенциальным исполнителем я бы спросил, что делать если я использую в составе разрабатываемой системы какой то опенсорсный кусок, надо ли мне менять там нотацию комментариев, например?)
Так точно 34 ГОСТ. И то с апреля этого года РД 50 отменили. Вообще печаль по документации становится. Но код в документацию на бумажке не включаем. В ведомственный gitlab грузить заставляем. Насчёт опенсорса, требования идут к коду который пишется исполнителем, если код поставляется готовый по лицензионному соглашению то требования не предъявляются. Вроде так логично.
источник
22:05пожаловаться

SB

Sergey Barmin in Kotlin Moscow
Ⓢⓔⓡⓖ
В эпоху Agile требовать документировать всё подряд - безумство
Выделить отдельный спринт на документирование)
источник
22:06пожаловаться

AN

Alexander Nozik in Kotlin Moscow
Если пишите для себя в замкнутой команде, можете писать докуменацию как угодно. Но если это либа или есть большая текучка кадров, то без документации нельзя.
источник
22:07пожаловаться

SM

Sergey Morgunov in Kotlin Moscow
Alexander Nozik
Категорически не согласен. Считаю самодокументируемый код вредным мифом.
О да 👍 Иной раз на одну строчку нужно написать целый параграф, чтобы объяснить какого хрена оно так, а не иначе 😀 Да ещё с ссылочкой на какую-нибудь статью где это объясняется ещё более подробно 😀 И чем ближе к системному коду, тем больше нужды в таких комментах 😀
источник
22:08пожаловаться

КБ

Константин Буланов in Kotlin Moscow
Alexander Nozik
Если пишите для себя в замкнутой команде, можете писать докуменацию как угодно. Но если это либа или есть большая текучка кадров, то без документации нельзя.
Плюсую. Ещё это полезно если разработчик системы одна команда, а сопровождает другая.
источник
22:09пожаловаться

AN

Alexander Nozik in Kotlin Moscow
Sergey Morgunov
О да 👍 Иной раз на одну строчку нужно написать целый параграф, чтобы объяснить какого хрена оно так, а не иначе 😀 Да ещё с ссылочкой на какую-нибудь статью где это объясняется ещё более подробно 😀 И чем ближе к системному коду, тем больше нужды в таких комментах 😀
Я обычно пишу хотя бы строчку по поводу того, что метод делает.
источник
22:09пожаловаться

Ⓢ

Ⓢⓔⓡⓖ in Kotlin Moscow
Ну и почему бы это (то, что он делает), не закодировать в его названии?
источник
22:10пожаловаться

Ⓢ

Ⓢⓔⓡⓖ in Kotlin Moscow
Закодировать = подобрать краткие и точные английские слова и перевести в camel case
источник
22:10пожаловаться

Ⓢ

Ⓢⓔⓡⓖ in Kotlin Moscow
Хотя я понимаю, что не всем быть Антонами Чеховыми.
источник
22:11пожаловаться

AN

Alexander Nozik in Kotlin Moscow
Ⓢⓔⓡⓖ
Ну и почему бы это (то, что он делает), не закодировать в его названии?
Нельзя все закодировать в названии. Одному это может быть очевидно, другому нет. Соглашения на параметры? Выкидываемые ошибки? тред сейфети?
источник
22:11пожаловаться

Ⓢ

Ⓢⓔⓡⓖ in Kotlin Moscow
И даже хотя бы Львами Толстыми не каждый сможет, а самое сложное - подобрать точные слова для описания того, что он делает
источник
22:11пожаловаться

SM

Sergey Morgunov in Kotlin Moscow
Ⓢⓔⓡⓖ
И даже хотя бы Львами Толстыми не каждый сможет, а самое сложное - подобрать точные слова для описания того, что он делает
Иногда важно не то, что он делает, а почему он делает это именно так, а не иначе. И это ни в каком названии не опишешь 😀
источник
22:12пожаловаться

КБ

Константин Буланов in Kotlin Moscow
Sergey Morgunov
Иногда важно не то, что он делает, а почему он делает это именно так, а не иначе. И это ни в каком названии не опишешь 😀
Такую экспертизу ведомство провести не может. У нас экспертиза будет дороже самих работ :)
источник
22:13пожаловаться

AN

Alexander Nozik in Kotlin Moscow
ключевые публичные API должны быть с коментами хотя бы даже для того, чтобы кдоки читабельные были
источник
22:14пожаловаться