Слушайте, но ведь пример абсолютно оторван от контекста. Утверждать что зависимостей прибавится или метод не будет работать не верно. Т.к. контекст не определен. Не Вы, не я не знаем что это за код и где он выполняется.
Я уже вообще пожалел, что написал что-то, т.к. написав все что угодно, можно интерпретировать как что-то, что является ошибкой, т.к. никакой конкретики в примере выше нет.
Ну и по поводу медленнее. Очень редко требуется оптимизировать, путем отказа от вызова метода. Даже чаще это явно лишнее. Отличный пример, это недавняя статья про Notepad++.
И резюмируя, ваш класс Hash ужасен. Что он делает я не понял. Обновляет какой то объект C? Хэш то вычисляется или нет? Если нет, почему класс называется хэш?
Вы же понимаете, что в зависимости от задачи может быть и соберусь. И зря вы так категоричны. :) К сожалению не знаю, во всех ли языках оператор << идентичен, но, если нет, я бы предпочел метод leftShift. Ну или не дай бог, я захочу логировать процесс получения хэша. Ну и т.д.
Опять таки, в зависимости от задачи, имя метода getHash может быть идеальным. Да, если вы делаете библиотеку, которая позволяет вычислять различные хэши, то название ужасное, не позволяет отделить одно от другой.
Но если в вашей системе, которая решает другую задачу, есть несколько методов получения хэша, то это плохо. Это гораздо хуже чем один метод, который просто возвращает хэш. Вам не нужно знать реализацию, вам нужен просто хэш. Имя метода GetHash идеально для этого.
Опять таки, тот коммент, который вы написали перед именем класса, это средства документирования. Я очень сильно за эти средства. Без них, я считаю что класс, метод не закончен.
Опять таки, что такое C, я категорически не понимаю. :)
Я понятия не имею что он делает и зачем. Я не знаю что такое c. Я не понял, вы подгоняли хэш, для какой то специфичной системы, у которой хэш имеет определенный формат или размер или что-то другое.
То, что вы добавили комментарий, не сделало код более читабельным. Это просто сноска, которая позволяет вам описать, что здесь происходит. Но код как был плохой, так и остался.
Вывод. Каждую часть перенести в функцию с нормальным описанием. Непонятные переменные в топку. Всю конструкцию прятать в функцию. Пока не получится что-то типа:
Не использую комментарии. Использую только возможности документирования (аля summary в C#). Всегда включаю ворнинги на отсутствие доки к функции/классу. Из комментов использую только подобия ToDo, что бы не забыть. Благо современные IDE позволяют собирать все эти ToDo и отображать отдельным списком, чем я и пользуюсь каждую неделю в пятницу утром, просматривая чего я еще не сделал.
Ни разу не было момента, когда комментарий был необходим. Всегда, когда коммент был необходим, приходилось заниматься рефакторингом, после которого, коммент был не нужен. Выводы очевидны.
Не знаю, к сожалению. Если Mail.ru хоть иногда всплывает (вопросы Mail.ru например при поиске в гугле), то вот Одноклассники не были востребованы вообще.
Зачем пытаются отделить одно от другого — не ясно. Это все отлично дополняет друг друга, главное не уходить в крайности. Хороший программист напишет программу как с использованием только ФП, так и только с использованием ООП и все будет работать и все будет понятно. И хороший программист напишет программу с использованием и ФП и ООП, скорее всего это будет лучше, чем использование только одной парадигмы.
Главное — писать нормальный, понятный код. Остальное — холивар для тех, кто умеет пользоваться чем то одним и не умеет пользоваться другим.
Всегда любил статьи, которые структурирует не совсем очевидные вещи, а не в стиле кэпа повторяют уже давно все сказанное.
Как мне кажется, основная сила этой статьи — это третий пункт, остальное, скорее, в стиле кэпа. Хотя, я понимаю что без этих пунктов статья была бы не полной и все было бы хуже. Но вот третий пункт отличный. НЕ очевидные но простые вещи, на мой взгляд.Отличные цитаты и примеры. Спасибо.
Может быть автор меня сейчас закидает камнями, но я не верю в идею универсальности платформы/языка. Поэтому сам по себе подход Full-Stack обречен на провал. НЕ существует платформы/языка, который покроет все мои «хотелки». Не существует языка/платформы/технологии которая умеет все. Я за то, что бы мое приложение было написано с использованием тех технологий/платформ/языков, которые сейчас подходят лучше всего для решения моей задачи, будь то клиент или сервер.
Для меня подобные шаги, как этот шаг с Лего, очень похожи просто на маркетинг. Т.е. это из разряда «прикольненько» и не более.
И да, для моделирования процесса разработки лучше использовать специализированные инструменты, если вы имели ввиду именно моделирование процесса разработки, а не визуализацию требований для анализа. А даже если и имели ввиду визуализацию требований, то тоже лучше так не делать, т.к. глаза заказчика, когда аналитик будет показывать проблему с помощью лего, я боюсь представить. :)
Так что, повторяю, кто конкретно выгрузил все данные по ключу нашей компании — они бы никогда не узнали.
Они бы узнали по логам, что для аутентификации использовался сертификат нашей компании и некий IP, возможно китайского прокси, с которого был доступ.
Так вот, виноват будет тот, кто договор подписывал (либо компания как ЮР. лицо). Т.к. он должен был соблюдать условия договора. Вы сейчас говорите не как взрослый человек, который понимает что такое договор и что такое ответственность по соблюдению договора.
Доки для методов — отлично.
Как мне кажется, даже комменты в функции langDetect не нужны.
Я уже вообще пожалел, что написал что-то, т.к. написав все что угодно, можно интерпретировать как что-то, что является ошибкой, т.к. никакой конкретики в примере выше нет.
Ну и по поводу медленнее. Очень редко требуется оптимизировать, путем отказа от вызова метода. Даже чаще это явно лишнее. Отличный пример, это недавняя статья про Notepad++.
Вы же понимаете, что в зависимости от задачи может быть и соберусь. И зря вы так категоричны. :) К сожалению не знаю, во всех ли языках оператор << идентичен, но, если нет, я бы предпочел метод leftShift. Ну или не дай бог, я захочу логировать процесс получения хэша. Ну и т.д.
Опять таки, в зависимости от задачи, имя метода getHash может быть идеальным. Да, если вы делаете библиотеку, которая позволяет вычислять различные хэши, то название ужасное, не позволяет отделить одно от другой.
Но если в вашей системе, которая решает другую задачу, есть несколько методов получения хэша, то это плохо. Это гораздо хуже чем один метод, который просто возвращает хэш. Вам не нужно знать реализацию, вам нужен просто хэш. Имя метода GetHash идеально для этого.
Опять таки, тот коммент, который вы написали перед именем класса, это средства документирования. Я очень сильно за эти средства. Без них, я считаю что класс, метод не закончен.
Опять таки, что такое C, я категорически не понимаю. :)
Вот этот код нечитабелен:
Я понятия не имею что он делает и зачем. Я не знаю что такое c. Я не понял, вы подгоняли хэш, для какой то специфичной системы, у которой хэш имеет определенный формат или размер или что-то другое.
То, что вы добавили комментарий, не сделало код более читабельным. Это просто сноска, которая позволяет вам описать, что здесь происходит. Но код как был плохой, так и остался.
Вывод. Каждую часть перенести в функцию с нормальным описанием. Непонятные переменные в топку. Всю конструкцию прятать в функцию. Пока не получится что-то типа:
Другая, медленная функция получения хэша вам вяд ли понадобится.
Не использую комментарии. Использую только возможности документирования (аля summary в C#). Всегда включаю ворнинги на отсутствие доки к функции/классу. Из комментов использую только подобия ToDo, что бы не забыть. Благо современные IDE позволяют собирать все эти ToDo и отображать отдельным списком, чем я и пользуюсь каждую неделю в пятницу утром, просматривая чего я еще не сделал.
Ни разу не было момента, когда комментарий был необходим. Всегда, когда коммент был необходим, приходилось заниматься рефакторингом, после которого, коммент был не нужен. Выводы очевидны.
Главное — писать нормальный, понятный код. Остальное — холивар для тех, кто умеет пользоваться чем то одним и не умеет пользоваться другим.
Как мне кажется, основная сила этой статьи — это третий пункт, остальное, скорее, в стиле кэпа. Хотя, я понимаю что без этих пунктов статья была бы не полной и все было бы хуже. Но вот третий пункт отличный. НЕ очевидные но простые вещи, на мой взгляд.Отличные цитаты и примеры. Спасибо.
И да, JavaScript отстой, это мое мнение.
И да, для моделирования процесса разработки лучше использовать специализированные инструменты, если вы имели ввиду именно моделирование процесса разработки, а не визуализацию требований для анализа. А даже если и имели ввиду визуализацию требований, то тоже лучше так не делать, т.к. глаза заказчика, когда аналитик будет показывать проблему с помощью лего, я боюсь представить. :)
=>
Но слово теоретически Вы не видите в упор. :) Да Вам бы заголовки желтых газет оформлять. :)
Так вот, виноват будет тот, кто договор подписывал (либо компания как ЮР. лицо). Т.к. он должен был соблюдать условия договора. Вы сейчас говорите не как взрослый человек, который понимает что такое договор и что такое ответственность по соблюдению договора.