Не серьёзно как-то… Выпрашивать подробности. Вы же делали проект, столкнулись (или нет?) с типичными highload проблемами? Как организовано многотопоточная (?) проверка доступности? Каких ресурсов это стоит? И т.п.
Презентация для развлечения аудитории. Сложность архитектуры foursquare остается додумывать самому на основе цифр из слайдов. Но лектор — интересный, с юмором.
Как показывает практика — за названиями функций следят большем, чем за поясняющими его комментариями. Все-таки название функции — это часть кода, она «читается». А комментарии — это некий «шум»
Зачем размазывать? Давно придумали замыкания. И когда потом, через полгода, вам вдруг внутри функции, которую вы привели, надо будет изменить реализацию метода — вы сходу его найдете. Все потому, что 1. функции-замкания, которые вы сделали — маленькие, 2. они делают только одну вещь — создают шрифт, рисуют что-то, правят и т.п.
Я раньше тоже не мог без комментариев. Но попробовав без них в js теперь не могу себя заставить заставить сделать огромную функцию с кучей действий в других языках. Если функция делает две вещи — значит вам нужны две функции :)
Есть несколько вещей, для которых все еще допустим использовать комментарии с моей точки зрения:
1. описание зудобробильных регулярок
2. пометка регрессионных unit-test'ов номером задачи из баг-трекера
3. Странные действия. Например, в каком-то тесте, в отличии от десятка других, мы проверяем свойства расписания не понедельника, а вторника. Полезно написать, что это сделано потому, что во вторник поезда выбранного направления, например, на мойке :) Хотя, даже это можно инкапсулировать в getTestWeekdayForTrainById(trainId) и туда зашить логику… Хм… Пойду вкоммичу.
Не лично вам, но все же
А когда код меняет свою суть, то комментарий не забываете обновлять?
Конкретно ваш пример прекрасно показывает то, что можно и без комментариев — достаточно лишь добавить немного функций createFont()
drawRectangle()
drawText()
extractRegion()
И все — теперь мы знаем, что делает код. Я скорее всего ошибся с названиями: их можно удлинить бОльшим количеством описания. В одном из проектов вполне можно было встретить что-то типа convertSingleSailInTwoSailsPerDayForMinskRoute()
Через интернет нельзя оплатить в указанное время суток. Единственный выход — купить где-нибудь карту предоплаты, и в личном кабинете пополнить с нее баланс.
Как хотел было скачать, но что за каменный век? Какое-то деление на «тома» файлов. Почему бы в виде торрента не выпустить? Да и просто, без торрента, слабо одним файлом? Фат32? Для таких ретроградов и ие6 хватит. Каменный век.
Я раньше тоже не мог без комментариев. Но попробовав без них в js теперь не могу себя заставить заставить сделать огромную функцию с кучей действий в других языках. Если функция делает две вещи — значит вам нужны две функции :)
Есть несколько вещей, для которых все еще допустим использовать комментарии с моей точки зрения:
1. описание зудобробильных регулярок
2. пометка регрессионных unit-test'ов номером задачи из баг-трекера
3. Странные действия. Например, в каком-то тесте, в отличии от десятка других, мы проверяем свойства расписания не понедельника, а вторника. Полезно написать, что это сделано потому, что во вторник поезда выбранного направления, например, на мойке :) Хотя, даже это можно инкапсулировать в getTestWeekdayForTrainById(trainId) и туда зашить логику… Хм… Пойду вкоммичу.
А когда код меняет свою суть, то комментарий не забываете обновлять?
Конкретно ваш пример прекрасно показывает то, что можно и без комментариев — достаточно лишь добавить немного функций
createFont() drawRectangle() drawText() extractRegion()И все — теперь мы знаем, что делает код. Я скорее всего ошибся с названиями: их можно удлинить бОльшим количеством описания. В одном из проектов вполне можно было встретить что-то типа
convertSingleSailInTwoSailsPerDayForMinskRoute()я думаю, все умерли именно от этого