Вообще очень странно, когда вроде все уже давно сошлись в том, что код чаще читается, чем пишется, но при этом программисты сами себе не хотят помочь, добавив дополнительную информацию
Вполне можно обойтись без копипасты и без полиморфизма.
Мне сложно представить, за исключением случая повсеместного использования паттернов, ситуацию когда нужно прям очень много полиморфных классов, ну скажем больше 5-10 разных интерфейсов на миллион строк кода
Полиморфный код не сильно лучше обычного. Если можно писать не полиморфно, то лучше писать не полиморфно.
Хотя это конечно может зависеть от стиля, выбранного в компании. Если у вас там паттерны на паттернах и паттернами погоняют, то да, полиморфного кода будет много, но в обычном проекте количество такого кода точно не сравнится с количеством auto
Это конечно логично, потому что i это уже сама по себе ссылка, но просто читать код в надежде выцепить из него все &mut уже недостаточно, в результате приходится вглядываться в код также пристально, как и в c++
Мне тоже кажется, что с типами лучше, чем с auto. Другое дело, что само имя контейнера как правило действительно не нужно. А вот лежащий в его основе тип еще как нужен. Было бы можно писать auto<Child>, было бы круто.
Очень тяжело читать код без типов, где вызываются функции вложенности 10, некоторые из них шаблонные.
В лямбде как раз тип особо не нужен, потому что лямбда тутже и определяется. Проще посмотреть на заголовок лямбды, чем пытаться вычислить тип. А когда эта лямбда передается куда-то, то уже стоит использовать std::function (хотя она и может нести в себе лишний оверхед над производительностью)
В трудовой ли дело? Подозреваю, что трудовая - лишь view на какую-то бд, которая (бд) применяется и для обычной (бумажной) книжки (стаж у людей и раньше пропадал)
Ну, если это действительно бэд блоки, а диск системный, то система довольно быстро "обнаружит" их, просто не загрузившись или каким-либо другим чудным глюком. По крайней мере на 2-х своих дисках (один hdd, другой ssd) я именно так узнал о появлении битых секторов. А если все работает нормально, то может и ну его?
mail ru фильтрует большую часть спама так, что она не доходит до почтового ящика, не попадает даже в папку спам. Я это заметил, когда нужные мне сообщения от людей до меня не доходили вообще. Кто знает, может у гугла тоже самое есть
Поможем найти работу, где получать будете ещё больше, а работать ещё меньше
Ну мне это не кажется прям оскарблением. Если уж только юмор. Вот если бы он намекал, что с такой "ответственностью" они вообще не найдут работу даже с такой зарплатой, то тогда да, было бы оскорбление
Я в свое время раза 2 перечитал письмо и ничего особо хамского по сути там не увидел. Наоборот, увидел некоторую заботу (типа "вам помогут найти...", хотя совсем не факт, что помогут). Обычно в дискуссиях про отношения предлагают намного более жестокое обращение.
Нужно сократить именно по причине «денег нет, извините, руководство облажалось»
Но нужно же как-то пояснить, по какому критерию выбирали тех, кого сократить. Или не нужно? Вот в чем вопрос.
А вот интересно, что лучше. Вот предположим, наступила в компании такая ситуация, когда денех нет, нужно сокращать штат. Нужно ли его сократить молча, без объяснения причин, или написать причину, хотя бы такую?
Вот это я к чему, обычно на хабре возникают жаркие дискуссии по поводу того, что если чел облажался, то послать его прямым текстом куда подальше или сильно завуалировать в виде "Все хорошо, здесь есть еще пара мест для оптимизаций". И из данной истории становится видно, что лучше было бы сделать это более обтекаемо.
При этом я не оцениваю качество именно самих метрик. Оценивать программистов по количеству статей в confluence - это никуда не годится. Речь я веду именно о форме подачи материала. То есть, вот есть какой-то критерий, по которому мы выбрали, кого уволить, неважно, хороший это критерий или плохой, стоит ли о нем сообщать на всеуслышанье?
Вообще очень странно, когда вроде все уже давно сошлись в том, что код чаще читается, чем пишется, но при этом программисты сами себе не хотят помочь, добавив дополнительную информацию
Вполне можно обойтись без копипасты и без полиморфизма.
Мне сложно представить, за исключением случая повсеместного использования паттернов, ситуацию когда нужно прям очень много полиморфных классов, ну скажем больше 5-10 разных интерфейсов на миллион строк кода
Полиморфный код не сильно лучше обычного. Если можно писать не полиморфно, то лучше писать не полиморфно.
Хотя это конечно может зависеть от стиля, выбранного в компании. Если у вас там паттерны на паттернах и паттернами погоняют, то да, полиморфного кода будет много, но в обычном проекте количество такого кода точно не сравнится с количеством auto
Или наоборот - огромное количество дремучего легаси
Не совсем. Если переменная передана как ссылка, то ссылку брать не требуется. Например, в таком примере
Для переменной j ссылка нужна, для i уже нет.
Это конечно логично, потому что i это уже сама по себе ссылка, но просто читать код в надежде выцепить из него все &mut уже недостаточно, в результате приходится вглядываться в код также пристально, как и в c++
Мне тоже кажется, что с типами лучше, чем с auto. Другое дело, что само имя контейнера как правило действительно не нужно. А вот лежащий в его основе тип еще как нужен. Было бы можно писать auto<Child>, было бы круто.
Очень тяжело читать код без типов, где вызываются функции вложенности 10, некоторые из них шаблонные.
В лямбде как раз тип особо не нужен, потому что лямбда тутже и определяется. Проще посмотреть на заголовок лямбды, чем пытаться вычислить тип. А когда эта лямбда передается куда-то, то уже стоит использовать std::function (хотя она и может нести в себе лишний оверхед над производительностью)
Так получается, электронная книжка оправдана?
Тем не менее, судя по новости, кто-то это все-таки обнаружил. Хотя вроде и раньше какую-то выписку можно было получить
В трудовой ли дело? Подозреваю, что трудовая - лишь view на какую-то бд, которая (бд) применяется и для обычной (бумажной) книжки (стаж у людей и раньше пропадал)
Но если тк электронная, то о потере стажа ты узнаешь сразу, а не постфактум, когда уже за пенсией придешь
Ну, если это действительно бэд блоки, а диск системный, то система довольно быстро "обнаружит" их, просто не загрузившись или каким-либо другим чудным глюком. По крайней мере на 2-х своих дисках (один hdd, другой ssd) я именно так узнал о появлении битых секторов. А если все работает нормально, то может и ну его?
А кто считается подчиненным в общем случае? Например, джун-сеньер, джун-миддл, это разграничение по "начальник-подчиненный" или нет?
И еще возможность поставить копирование в очередь, а не в параллель
А это как-то гарантирует, что производитель точно также не сможет окирпичить тело?
mail ru фильтрует большую часть спама так, что она не доходит до почтового ящика, не попадает даже в папку спам. Я это заметил, когда нужные мне сообщения от людей до меня не доходили вообще. Кто знает, может у гугла тоже самое есть
Хм. Мне почемуто гуглится такое. Хотя дальше заголовка я не читал, но вроде все законно
https://rg.ru/2016/01/19/pokupka.html#:~:text=Гражданам%2C%20которые%20захотят%20купить%20ювелирные,путем%2C%20с%20помощью%20банковской%20карты.
Недавно папа покупал бижутерию за наличку, попросили паспорт
Ну мне это не кажется прям оскарблением. Если уж только юмор. Вот если бы он намекал, что с такой "ответственностью" они вообще не найдут работу даже с такой зарплатой, то тогда да, было бы оскорбление
Я в свое время раза 2 перечитал письмо и ничего особо хамского по сути там не увидел. Наоборот, увидел некоторую заботу (типа "вам помогут найти...", хотя совсем не факт, что помогут). Обычно в дискуссиях про отношения предлагают намного более жестокое обращение.
Но нужно же как-то пояснить, по какому критерию выбирали тех, кого сократить. Или не нужно? Вот в чем вопрос.
А вот интересно, что лучше. Вот предположим, наступила в компании такая ситуация, когда денех нет, нужно сокращать штат. Нужно ли его сократить молча, без объяснения причин, или написать причину, хотя бы такую?
Вот это я к чему, обычно на хабре возникают жаркие дискуссии по поводу того, что если чел облажался, то послать его прямым текстом куда подальше или сильно завуалировать в виде "Все хорошо, здесь есть еще пара мест для оптимизаций". И из данной истории становится видно, что лучше было бы сделать это более обтекаемо.
При этом я не оцениваю качество именно самих метрик. Оценивать программистов по количеству статей в confluence - это никуда не годится. Речь я веду именно о форме подачи материала. То есть, вот есть какой-то критерий, по которому мы выбрали, кого уволить, неважно, хороший это критерий или плохой, стоит ли о нем сообщать на всеуслышанье?