Я хотел сказать, что большинство обновлений от мелкомягких стоит того, чтобы их установить. Некоторые да, что-то периодически ломают, но баги увы случаются у всех, даже у мультимиллиардных корпораций.
Я лично бы действительно не называл переменную string, назвал бы как-либо иначе (см. выше). Я согласен с данной рекомендацией.
Но если на код ревью автор очень хочет так назвать, то я бы не очень сильно сопротивлялся. Важнее сохранить хорошие отношения в команде. А ещё это было бы хорошей "разменной картой" — уступить в одном месте, в обмен на другое изменение.
Но обычно инженеры после 10-15 лет опыта работы приходят к выводу, что из пункта А в пункт Б можно придти разными путями. И если путей видно несколько и ни у одного нет явных недостатков, то выбор — дело вкуса (опыта, предпочтений, предрассудков).
Никаких best practices НЕ использовать extension methods не существует. Вы их выдумали. Насаждать личные предпочтения под видом "правил" — проявление непрофессионализма. А никак не наоборот.
Вы это "правило" только что придумали. Extension methods созданы для расширения чужих типов, в особенности — встроенных/системных.
Спор за/против extension methods стоит ровно ничего, он бессмысленный и ни к чему не приводит. Потому что в итоге сводится к личным предпочтениям в стиле кода.
Абьюз — плохо, нормальное применение (как в данном случае) — нормально.
Я бы назвал переменную str или value или input. Специально чтобы не добавлять @ но это чистой воды "вкусовщина" — нет ни правых, ни виноватых. Дело вкуса, предпочтений, и личных предрассудков.
Не выдумывайте, пожалуйста. Методы расширения (as in extension methods) созданы специально для… расширения других типов. ToUpper(), ToLower() уже есть, что делает ToSnake() идеальным кандидатом.
Метод ExecuteResultAsync() можно/нужно переписать в виде одного LINQ-выражения. Будет меньше кода, меньше потенциальных ошибок, а так же потрачено меньше памяти и процессора: не нужен ни дополнительный массив, но лист.
Любители on-prem считают, что все те люди, которые нужны чтобы поддерживать ДЦ в рабочем состоянии, уже есть (наняты, обучены, мотивированны, а главное эту мотивацию ни при каких условиях не теряют), а зарплата им берётся из воздуха.
Поменялось очень много. Не всё, но многое. Решение по слухам принял VP подразделения.
Я хотел сказать, что большинство обновлений от мелкомягких стоит того, чтобы их установить. Некоторые да, что-то периодически ломают, но баги увы случаются у всех, даже у мультимиллиардных корпораций.
Вы не правы :) Всё
значительнонесколько сложнее.По-моему — ровно наоборот. Я не люблю статические публичные хелперы, типа Utils.DoSomething(foo, 44). Вместо них предпочитаю extensions methods.
Вам не нравятся extensions methods, мы уже поняли :)
Я лично бы действительно не называл переменную string, назвал бы как-либо иначе (см. выше). Я согласен с данной рекомендацией.
Но если на код ревью автор очень хочет так назвать, то я бы не очень сильно сопротивлялся. Важнее сохранить хорошие отношения в команде. А ещё это было бы хорошей "разменной картой" — уступить в одном месте, в обмен на другое изменение.
Бывает и так.
Но обычно инженеры после 10-15 лет опыта работы приходят к выводу, что из пункта А в пункт Б можно придти разными путями. И если путей видно несколько и ни у одного нет явных недостатков, то выбор — дело вкуса (опыта, предпочтений, предрассудков).
Никаких best practices НЕ использовать extension methods не существует. Вы их выдумали. Насаждать личные предпочтения под видом "правил" — проявление непрофессионализма. А никак не наоборот.
Вероятность такой коллизии неотличима от 0.
Вы это "правило" только что придумали. Extension methods созданы для расширения чужих типов, в особенности — встроенных/системных.
Спор за/против extension methods стоит ровно ничего, он бессмысленный и ни к чему не приводит. Потому что в итоге сводится к личным предпочтениям в стиле кода.
Абьюз — плохо, нормальное применение (как в данном случае) — нормально.
Я бы назвал переменную str или value или input. Специально чтобы не добавлять @ но это чистой воды "вкусовщина" — нет ни правых, ни виноватых. Дело вкуса, предпочтений, и личных предрассудков.
Не выдумывайте, пожалуйста. Методы расширения (as in extension methods) созданы специально для… расширения других типов. ToUpper(), ToLower() уже есть, что делает ToSnake() идеальным кандидатом.
Метод ExecuteResultAsync() можно/нужно переписать в виде одного LINQ-выражения. Будет меньше кода, меньше потенциальных ошибок, а так же потрачено меньше памяти и процессора: не нужен ни дополнительный массив, но лист.
Не GIT, а Git. Не пойму откуда взялась мода писать заглавными буквами. Это же не JAVA и не PERL. Правда ни то, другое — тоже не аббревиатуры.
Надо сказать спасибо что ответили
Fair enough, как говорится. Но одно не отменяет другого.
Любители on-prem считают, что все те люди, которые нужны чтобы поддерживать ДЦ в рабочем состоянии, уже есть (наняты, обучены, мотивированны, а главное эту мотивацию ни при каких условиях не теряют), а зарплата им берётся из воздуха.
Этой индустрии никогда и не существовало.