Вы неправильно понимаете назначение заголовочных комментариев. Как и в остальных комментариях, там должно быть не то, что уже написано в коде, а то, чего в коде, как минимум, явно, нет. Назначение класса (что вовсе не обязано совпадать с тем, что он делает), архитектурные ограничения, поддержка многопоточности, принятые в нем особенности работы с транзакциями и т.п.
В Java-мире учиться писать комментарии можно на примере JRE и spring-core
Логгирование предназначено немного не для этого. Если о предназначении кода можно догадаться только по текстовым строкам логгирования, то у меня плохие новости о качестве вашего кода...
Логгирование не должно упрощать понимание кода, тем более сильно.
У меня java background, мне можно. Там принято фигурную скобку на той же строке открывать.
В C++, имхо, лучше не бежать поперек паровоза и использовать принятый там (и командой) стиль кода. Классика же — холиварность вопроса прямо пропорциональна его незначительности.
Взять меня — я был С++ разработчиком, ставил фигурные скобки с новой строки и обожал табы. При переходе на java пришлось подстроиться под команду и я от этого только выиграл. Например, на ревью было больше вопросов по делу и меньше по всякой фигне типа фигурных скобочек :-)
11. Не стесняйтесь вставлять пустые строки, разделяя смысловые блоки в рамках одной функции 12. Над каждым публичным классом и каждой публичной функцией должен быть комментарий. Да, код самодокументируемый и всё такое, но для этого его надо прочитать и осознать 13. В сложных местах (особенно если у будущего читателя может появиться желание "упростить" код) должен быть комментарий, объясняющий, почему было сделано именно так 14. самодокументируемого кода не бывает, бывает документированный код и недокументированный код
Изначально адекватно оценить бюджет проекта? Не, не слышал. Надо подписать договор на максимально возможную сумму, а потом уже думать, как сделать подешевле.
Подешевле — это вполне разумное и рациональное пожелание, но надо же адекватно оценивать риски? Что фронтендера за еду не найдут, что бэкендер не захочет работать в два раза больше на две роли за полуторную зарплату… Хотя, возможно, такой подход к бизнесу и разработке все равно коммерчески выгодней.
Не думали про композитный подход? когда korolev component может содержать css/js? Когда первоначальный рендер происходит на сервере, а динамическое обновление html возможно как по инициативе сервере, так и по инициативе клиента — либо запросом ререндера с сервера, либо прямой манипуляцией DOM.
Это всё хорошо и правильно, но отнимает много времени, которое можно было бы потратить на любимое дело — на программирование.
Программист с развитыми навыками менеджера — золотое дно для компании и первый кандидат на повышение в должности и зарплате. Но придется отказаться от программирования.
Такие аргументы обычно используются в корпоративной борьбе. Пофиг что не SOAP, пофиг, что не WSDL, ОНИ ПОТРАТИЛИ ДЕНЬГИ БИЗНЕСА, вместо того, чтобы взять уже написанное бесплатно!
После такого вброса уже сложно объяснять кумулятивную разницу между заточенным на свои нужды велосипедом и затратами на уже готовое решение.
Не совсем понятно. Библиотека сделана для случая, когда и фронт, и бэк на node.js и шарят общую схему, написанную руками?
Я бы предпочел кодогенерацию клиентского и серверного кода. Проще добавлять новые языки и протоколы, проще пользоваться — в сгенеренном коде нет никакой магии.
РСУБД имеют очень интересное свойство — данные в РСУБД имеют ценность даже без приложения, которое эти данные породило. С графовыми субд сложнее — сравните наглядность визуализатора таблиц (эксель) и визуализатора графов (до сих пор нет единого мнения, как их правильно визуализировать)
Типы для составных сущностей (таблиц) не очень полезны, т.к. строки идентифицируются суррогатным ключом, а "тип суррогатного ключа" документируется и валидируется соответствующим FK
Структуры в полях таблиц — нууу, их начали добавлять под соусом json
Суррогатные ключи вместо указателей в графовых данных — в РСУБД они так и хранятся.
Похоже, основное отличие современной реляционной субд от графовой — это физическая организация данных, оптимизированная под соответствущие типы запросов (сканирование таблиц vs переход по FK единственного объекта(строки))
ага, инициализацию локальных переменных в одну функцию, цикл в другую, оператор return — в третью.
По статье по ссылке — посмотрите сами на его пример отрефакторенного кода. Разве не хочется добавить простора? между методами, внутри метода
lines()?edit: вот ваше сообщение состоит из 3 предложений, и вы все равно разбили их на два абзаца. Чем код хуже?
Вы неправильно понимаете назначение заголовочных комментариев. Как и в остальных комментариях, там должно быть не то, что уже написано в коде, а то, чего в коде, как минимум, явно, нет. Назначение класса (что вовсе не обязано совпадать с тем, что он делает), архитектурные ограничения, поддержка многопоточности, принятые в нем особенности работы с транзакциями и т.п.
В Java-мире учиться писать комментарии можно на примере JRE и spring-core
Это, случаем, не разновидность задачи поиска кратчайшего пути во взвешенном графе?
Логгирование предназначено немного не для этого. Если о предназначении кода можно догадаться только по текстовым строкам логгирования, то у меня плохие новости о качестве вашего кода...
Логгирование не должно упрощать понимание кода, тем более сильно.
У меня java background, мне можно. Там принято фигурную скобку на той же строке открывать.
В C++, имхо, лучше не бежать поперек паровоза и использовать принятый там (и командой) стиль кода. Классика же — холиварность вопроса прямо пропорциональна его незначительности.
Взять меня — я был С++ разработчиком, ставил фигурные скобки с новой строки и обожал табы. При переходе на java пришлось подстроиться под команду и я от этого только выиграл. Например, на ревью было больше вопросов по делу и меньше по всякой фигне типа фигурных скобочек :-)
Я бы сделал вот так:
11.Не стесняйтесь вставлять пустые строки, разделяя смысловые блоки в рамках одной функции12.Над каждым публичным классом и каждой публичной функцией должен быть комментарий. Да, код самодокументируемый и всё такое, но для этого его надо прочитать и осознать13.В сложных местах (особенно если у будущего читателя может появиться желание "упростить" код) должен быть комментарий, объясняющий, почему было сделано именно так14.самодокументируемого кода не бывает, бывает документированный код и недокументированный кодЭто всё ужасно, но если этим пользуются, то, наверное, оно работает?
Почему вы на незнакомых вам людей клеите ярлыки, искажете их слова и обвиняете их во лжи?
Изначально адекватно оценить бюджет проекта? Не, не слышал. Надо подписать договор на максимально возможную сумму, а потом уже думать, как сделать подешевле.
Подешевле — это вполне разумное и рациональное пожелание, но надо же адекватно оценивать риски? Что фронтендера за еду не найдут, что бэкендер не захочет работать в два раза больше на две роли за полуторную зарплату… Хотя, возможно, такой подход к бизнесу и разработке все равно коммерчески выгодней.
Не думали про композитный подход? когда korolev component может содержать css/js? Когда первоначальный рендер происходит на сервере, а динамическое обновление html возможно как по инициативе сервере, так и по инициативе клиента — либо запросом ререндера с сервера, либо прямой манипуляцией DOM.
Это всё хорошо и правильно, но отнимает много времени, которое можно было бы потратить на любимое дело — на программирование.
Программист с развитыми навыками менеджера — золотое дно для компании и первый кандидат на повышение в должности и зарплате. Но придется отказаться от программирования.
Зачем тогда нужна схема? Если нужно написать просто клиент к стороннему апи, можно обойтись обычной моделью и интерфейсами вместо схемы.
Такие аргументы обычно используются в корпоративной борьбе. Пофиг что не SOAP, пофиг, что не WSDL, ОНИ ПОТРАТИЛИ ДЕНЬГИ БИЗНЕСА, вместо того, чтобы взять уже написанное бесплатно!
После такого вброса уже сложно объяснять кумулятивную разницу между заточенным на свои нужды велосипедом и затратами на уже готовое решение.
Не совсем понятно. Библиотека сделана для случая, когда и фронт, и бэк на node.js и шарят общую схему, написанную руками?
Я бы предпочел кодогенерацию клиентского и серверного кода. Проще добавлять новые языки и протоколы, проще пользоваться — в сгенеренном коде нет никакой магии.
Не раскрыты действительно животрепещущие вопросы:
Инициирует-не инициирует. Яндекс расположен в РФ, поэтому можно и штраф выписать, и конкретных ответственных найти.
Гугл проиграл борьбу с ФБР, яндекс ждет та же судьба.
А существует ли проблема?
РСУБД имеют очень интересное свойство — данные в РСУБД имеют ценность даже без приложения, которое эти данные породило. С графовыми субд сложнее — сравните наглядность визуализатора таблиц (эксель) и визуализатора графов (до сих пор нет единого мнения, как их правильно визуализировать)
Типы для составных сущностей (таблиц) не очень полезны, т.к. строки идентифицируются суррогатным ключом, а "тип суррогатного ключа" документируется и валидируется соответствующим FK
Структуры в полях таблиц — нууу, их начали добавлять под соусом json
Суррогатные ключи вместо указателей в графовых данных — в РСУБД они так и хранятся.
Похоже, основное отличие современной реляционной субд от графовой — это физическая организация данных, оптимизированная под соответствущие типы запросов (сканирование таблиц vs переход по FK единственного объекта(строки))
curl 0x0238f06aЗабавно, чего только в линукс не вкручивают.
На хабре сезон статей "менеджмент пожадничал выбрасывать MVP/прототип"