В Java, кстати, его и не делают, насколько я знаю. Тут вопрос не в том, нужен он или нет, вопрос в том, чтобы писать привычный для шарпистов код на C#. По крайней мере, меня убедили именно таким аргументом.
А по читаемости — ну да, так и есть. Но мы же это обычно обсуждаем. Вот у меня был кейс, что тимлид буквально хейтил вертикальные вайтспейсы. Не ставил их нигде, ещё и линтер настроил. В итоге нам удалось его переубедить. Потому что мотивация то у него была правильная — писать красивый и читабельный код.
Ну я на самом деле тут ответил агрессией на агрессию. По большому счету, речь ни идёт ни о каких эталонах. Вопрос в приоритетах и трейдофах. Т.е. не так важно, читабельный код на самом деле или нет, важно, пытаюсь ли я сделать его читабельным.
Достаточно в них просто не заходить. Но вас ведь не сами статьи бесят, вы недовольны их рейтингом и положением — и вот с этим-то вам ничего не поделать, сколько скриптов не напиши
Ну, в идеальном мире. В реальном мире, ну блин, ну не пишут эти требования. А если пишут, то недостаточно детально. А если достаточно детально, то они устаревшие. Я не знаю. Я работал в гигантских и крутых компаниях, где есть ресурсы на такие вещи — но даже там качественно расписанных требований днем с огнем не сыщешь.
А как смотрел? Я вот покопал немного тему бенчмарка, и понял, что тут или хорошо умеешь — или не берись. Результаты на дебаге и на релизе абсолютно разные. Результаты на разных процессорах абсолютно разные. Любое приложение, например WebStrom, работающее во время бенчмарка, способно влиять на результаты этого бенчмарка непредсказуемым образом. При разной температуре процессора результаты могут радикально отличаться. На одних размерах данных будет побеждать один способ, на других — другой. А потом ты опят увеличиваешь размер данных, и результат снова противоположный. Т.е. я говорю не о маленьких погрешностях — результаты могут быть буквально противоположными из-за такой мелочи, как одно запущенное стороннее приложение. И это — верхушка айсберга.
В Java, кстати, его и не делают, насколько я знаю. Тут вопрос не в том, нужен он или нет, вопрос в том, чтобы писать привычный для шарпистов код на C#. По крайней мере, меня убедили именно таким аргументом.
Всё нормально, меня уже убедили, что я болван (тупой)
Интересно. В js классы — это же сахар над прототипами, насколько я знаю
Так на беке можно развернуть усредненный рантайм. Но главное тут не это — стерильные условия дают воспроизводимость.
Полагаю, большинство пользователей как минимум имеют куда более ограниченную машину, чем я
Если на фронте, то это очень так себе. Получается, что условия не стерильные
Да какой диалог. Меня задели, я насрал в ответ.
А по читаемости — ну да, так и есть. Но мы же это обычно обсуждаем. Вот у меня был кейс, что тимлид буквально хейтил вертикальные вайтспейсы. Не ставил их нигде, ещё и линтер настроил. В итоге нам удалось его переубедить. Потому что мотивация то у него была правильная — писать красивый и читабельный код.
Ну я на самом деле тут ответил агрессией на агрессию. По большому счету, речь ни идёт ни о каких эталонах. Вопрос в приоритетах и трейдофах. Т.е. не так важно, читабельный код на самом деле или нет, важно, пытаюсь ли я сделать его читабельным.
Достаточно в них просто не заходить. Но вас ведь не сами статьи бесят, вы недовольны их рейтингом и положением — и вот с этим-то вам ничего не поделать, сколько скриптов не напиши
Да. Вот что-что, а дока должна именно философии учить.
Я бы вышвырнул из профессии людей, которые пишут нечитабельный и неподдерживаемый код.
Это Median. Ниже есть AlternateElements, не агрегирующий
О чем и речь
В любой истории должен быть свой мудак. Ну вот, работает оно так, не я это придумал, и не мне это менять.
Ну, в идеальном мире. В реальном мире, ну блин, ну не пишут эти требования. А если пишут, то недостаточно детально. А если достаточно детально, то они устаревшие. Я не знаю. Я работал в гигантских и крутых компаниях, где есть ресурсы на такие вещи — но даже там качественно расписанных требований днем с огнем не сыщешь.
Да, непонимание философии LINQ — это проблема. Но само решение, которое рушит эту философию — не критичное. Вот например майки в доку положили именно такое решение, и не чешутся https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/concepts/linq/how-to-add-custom-methods-for-linq-queries
А он не шутит и не сарказмирует. Если ноут черный и лежит на солнце, термальный тротлинг может спутать все карты
Ну вот зачем так? Есть у меня и другие статьи без нытья, например
https://habr.com/ru/post/506088/
А как смотрел? Я вот покопал немного тему бенчмарка, и понял, что тут или хорошо умеешь — или не берись. Результаты на дебаге и на релизе абсолютно разные. Результаты на разных процессорах абсолютно разные. Любое приложение, например WebStrom, работающее во время бенчмарка, способно влиять на результаты этого бенчмарка непредсказуемым образом. При разной температуре процессора результаты могут радикально отличаться. На одних размерах данных будет побеждать один способ, на других — другой. А потом ты опят увеличиваешь размер данных, и результат снова противоположный. Т.е. я говорю не о маленьких погрешностях — результаты могут быть буквально противоположными из-за такой мелочи, как одно запущенное стороннее приложение. И это — верхушка айсберга.
Справедливости ради, наколенные бенчи — абсолютно не показательны. Но в то что у них Map медленнее Objecta отдает по ключу — меня точно не удивит)