Я слышал, что в Telegram одни олимпиадники и пишут сложно, но тут вроде ок)

так webogram неофициальный же, не?

или уже официальный?

Кстати, достаточно неплохо написан код: https://github.com/zhukov/webogram/blob/master/app/js/messages_manager.js

ни одного комментария, отличный код!

к коду надо спеку писать, а не комментарии -_-

типичный вебдев

а, ну размещено на telegram.org, значит официальный)

ни одного комментария, отличный код!

Большинство комментариев, что я видел, только мешают)

Большинство комментариев, что я видел, только мешают)

видимо читать приходилось только свой собственный код?

Нет конечно же :)

Дело в том, что у большинства программистов не очень хорошо получается писать понятный текст. Поэтому то, что называется "самодокументируемый" код чаще всего лучше работает. Опять же, README и базовые вещи описанные отдельно всё равно необходимо, особенно для ввода в проект.

отсутствие доков в слаботиповом языке

Дело в том, что у большинства программистов не очень хорошо получается писать понятный текст. Поэтому то, что называется "самодокументируемый" код чаще всего лучше работает. Опять же, README и базовые вещи описанные отдельно всё равно необходимо, особенно для ввода в проект.

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

такая себе история

Если мы возмём React, важность типов переоценена. Разве propTypes не являются спекой?

@DenisIzmaylov под спекой я подразумеваю unit-test

в форме спеки )

А вот это да. Но тут схожая проблема - кейсы для тестирования. Можно сделать юнит-тест, в котором проверяется соответствие render заданному HTML и всё.

Coverage конечно решит отчасти)

Но не гарантирует все кейсы

Кто-то недавно писал статью, что тестирования нужно всегда с рандомными данными, иначе смысл тестов теряется

Образно говоря, brute force на поиск ошибки )

ну, вот что у нас в команде стараемся использовать(кроме попыток к tdd, но не всегда получается и не всегда нужно). Если вдруг ты захотел к своему коду написать комментарий или к старому коду, вынеси это в спеку и покрой тестом(а потом как у Фаулера написано, пробуй рефакторить). Плюс таких описательных спек в том, что они напоминают о себе, в отличие от простых комментов

Кто-то недавно писал статью, что тестирования нужно всегда с рандомными данными, иначе смысл тестов теряется

получить мигающие тесты тоже не хочется

от БЭМа даже в Яндексе на react-redux проекте отказались) он не очень вписывается

На самом деле там с бэм-стека перешили на реакт-редакс (в одной команде). Но тенденция к смене стека есть

Правда от методологии БЭМ никто не отказывается

ну, вот что у нас в команде стараемся использовать(кроме попыток к tdd, но не всегда получается и не всегда нужно). Если вдруг ты захотел к своему коду написать комментарий или к старому коду, вынеси это в спеку и покрой тестом(а потом как у Фаулера написано, пробуй рефакторить). Плюс таких описательных спек в том, что они напоминают о себе, в отличие от простых комментов

а можно примерно такой “описательной” спеки

получить мигающие тесты тоже не хочется

"Пишем тесты для тестов"?)

Gordey банальный it throws exception if first arg less than second

"Пишем тесты для тестов"?)

не знаю кто как, но у нас тесты для проектирования внешнего api разрабатываемых компонент, для возможности refactoring'a

@DenisIzmaylov да и в тестах же не всегда надо сравнить вход-выход. Например, во фронте да и вообще мало где принято использовать мутационное тестирование. Да что уж там, 100% покрытие мало где нужно, откровенно говоря, потому что цена ошибки у нас гораздо меньше, заплатку можно вылить в течение 5 минут, а то и меньше. Вот электронщикам надо загоняться, потому что отозвать платы на миллионы долларов не покатит, а мы, если затянем разработку на 10 и более % по времени просто потратим деньги бизнеса, хотя теже ошибки могли найти гораздо дешевле

не знаю кто как, но у нас тесты для проектирования внешнего api разрабатываемых компонент, для возможности refactoring'a

Вот это хорошо, да. Но мы дискуссию начали именно с того, что комментарии внутри кода не являются панацеей.

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

Вот это хорошо, да. Но мы дискуссию начали именно с того, что комментарии внутри кода не являются панацеей.

а что противоречит исходному?

Конечно, я же в пример привёл именно код внутреннего модуля, как пример неплохого самодокументируемого кода по бизнес-логике, а не стэк интеграции :)

процесс проектирования внешнего(для юнита) api: 1. создаем файл спеки 2. пишем хочу чтобы оно делал так 3. имплементим 4. хочу, чтобы оно еще делало так, если было изначально вот так 5. имплементим

и т.д.

вот эти 2 и 4 явно описываются в тесте и самим тестом, поэтому получается, что и комментарий не нужен

ну при этом все советы из clean code и всего такого

А что за clean code? Какие советы?

ну я про книжку

дяди Боба)

старина Мартин

вообще, опять же, все зависит от задач, которые возлагаются на тесты

у нас - документирование кода + проверка внешнего api, помогает не писать комменты и спокойно рефакторить в будущем

Конечно, я же в пример привёл именно код внутреннего модуля, как пример неплохого самодокументируемого кода по бизнес-логике, а не стэк интеграции :)

честно говоря, я все равно не понял(

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

Согласен, комменты в коде неочень хорошо.

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

?

звучит странно, честно говоря.

а что надо смотреть в рефах?

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

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

ну либо <img ref={c=>this.imageMounted(c)}/>

Поковыряю, спасибо

Согласен, комменты в коде неочень хорошо.

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

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

более чем согласен

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

внезапно для этого тесты, а не коменты

внезапно для этого тесты, а не коменты

Внезапно, я не про логику.

Я за тесты, но ими не покажешь всего.

например?

ERROR: S client not available

Например либу которую ты используешь с багом, есть ишью который вот вот решится, ты делаешь заплатку, пишешь // TODO: пока вот так, см. сюда: https://github...

ну, и в чем проблема покрыть это в тесте?

я серьезно, ровно тоже самое, но не в комменте, а в спеке+проверили, что этот баг мы правильно хендлим

при рефакторинге это еще и проверится

Лан, убедил :D Я ленив на такие тесты.

все же места вроде // regexp for email /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+)*\.(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|travel|mobi|[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i

лучше комментить

const emailRegex = //;

еще варианты)

все же места вроде // regexp for email /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+)*\.(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|travel|mobi|[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i

xyz где?

Из-за таких вот у меня и не принимают мой email

http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html

имхо для клиента const emailRegex=/^.+@.+\..+$/

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

комментов

имхо для клиента const emailRegex=/^.+@.+\..+$/

fakeemail@fake.fake

компоненты должны быть небольшими, к слову

выше кто-то кидал компонент на 10к строк. Или это не в этом чате)

лол

fakeemail@fake.fake

так и норм

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

компоненты должны быть небольшими, к слову

в идеале не только компоненты)

выше кто-то кидал компонент на 10к строк. Или это не в этом чате)

Из ангулярного телеграма?

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

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

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

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

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

мы для этого юзаем gherkin + cucumber.js

мы для этого юзаем gherkin + cucumber.js

??

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

Ну у меня в основном получаются тудушки и описание багфиксов технологий

Но я про комментарии в коде

Описание функции / модуля — ок

Ну у меня в основном получаются тудушки и описание багфиксов технологий

Простой пример: мне как то данные приходили из сервиса в плохом виде, мне надо было их смаппить. Я оставил комментарий с пояснением и туду на выпиливание маппинга после фикса сервиса.