В противовес массив как аргумент функции. Для чего нужна еще одна сущность, если есть массивы?

Проблема та же, что и с аут параметрами - нужно предварительно объявить, зачастую инициализировать бесполезным начальным значением, а только потом использовать. Т.е. нужно писать кучу ненужного кода, потому что язык такой - костыли.

надо тру-катчить каждый парсе

А сколько их по твоему будет на 100 исключений в файле?

Я серьезно. Не пиши этих букв. Просто "gut" или "Sehr gut" или "Verhandlungssicher".

Эти буквы нужны, если сертификат попросят. Мне говорили, что если тебя подозревают даже, что ты не носитель языка, то требуют сертификат (типа им тоже нужно формально отбрехаться - а конкретные буквы и сертификаты им в этом помогают). С другой стороны, ты сразу показываешь, что ты "таджик понаехавший". Впрочем, если чел не идиот, то и "гут" и "зер гут" тоже показывают, что ты "таджик".

чем отличается out от ref

-----

https://www.geeksforgeeks.org/difference-between-ref-and-o...

2 и 4 в табличке внизу.

Там можно копать и копать. Например, а можно ли ссылочный тип передать по ссылке и зачем это делать. На собесах любят копать, особенно если вопрошающий сам недавно это узнал и специально проштудировал, чтобы такими вопросами валить кандидатов. ))

Это уже не принципиально. Важно то что есть ситуации

Встреча определенного состояния - это и есть ситуация. Таким образом собственное исключение выбрасывается тогда, когда в этой определенной ситуации нет смысла продолжать выполнять задание дальше. Задание прочитать файл построчно и подсчитать количество ошибок. Если это неправильный файл, совсем, не тот формат, тут нечего считать. Мы не можем в принципе работать с этом файлом. Тут эксцепшион. А вот конкретные места файла, которые нам не нравятся, можно и нужно считать без ексцепшиона

Короче говоря, если тебе надо чтобы функция возвращала больше одного значения - кортеж хорошее решение. С другой стороны, использование кортежей (aka необходимость возвращать несколько значений) оправдано практически никогда, так что говорит скорее о плохом дизайне :)

Ни одному правилу не нужно следовать всегда и везде. А то некоторые сектанты заставляют писать развесистые деревья из вызывающих друг друга функций, чтобы только удовлетворить мантре, что функция возвращает только одно значение. Вместо того, чтобы написать курц и шнелль одну функцию с возвратом кортежа.

Примером тому goto, о котором легенды аж слагают, какой он плохой и всё такое - никогда не используйте... но есть мол пара случаев, когда он подходит. Бугага, оператор, который подходит под пару редких случаев - ради этого мы тащим его из языка в язык уже полвека.

Мы не можем в принципе работать с этом файлом.

Расскажи это своему заказчику

Не подозревай - нуллабельные типы были раньше.
Не встроенные, но сторонние.
Сути это не меняет.

Это кардинально меняет суть. int.TryParse - часть фреймворка, если во фреймворке нет нуллабельного типа, то его нельзя использовать.

А для меня есть хоть какая-то разница как оно имплементировано?

Ты утверждаешь, что TraParse не имеет исключений, но на самом деле этот метод работает с исключениями, просто тебе об этом не сообщает. TryParse просто тупо проглатывает исключения.

Или ты хочешь сделать так
bool res1 = int.TryParse(myStr1, out int val1);
bool res2 = int.TryParse(myStr2, out int val2);

bool res3 = int.TryParse(myStr3, out int val3);
и т.д.
и сказать что это правильно?

Я говорю, что все зависит от задачи. А код

int.TryParse(myStr1, out int val1);
int.TryParse(myStr2, out int val2);

int.TryParse(myStr3, out int val3);
и т.д.

вполне может быть правильным. Также как и другие варианты.

зачастую инициализировать бесполезным начальным значением

Это не нужно, в остальном логичная ситуация. У меня есть мешок (декларация), я даю его тебе (передача как реф-аргумента), ты его наполняешь и после окончания твоей работы как функции у меня остается наполнеnный мешок. Все интуитивно понятно. Часть кода само собой разумееющаяся, но если опустить декларацию, то получается хренова лямбда - код больше не связный текст, а обрывки слов заикающегося человека, которого ты понимаешь только потому, что с ним живешь.

Сказал, как отрезал.
навскидку: вот нужна мне функция, которая выдаёт корни квадрантного уравнения
Или функция, которая выдаёт немецкую календарную неделю: kw, year переданной даты.

Заводи класс (который только тут и будет использоваться), возвращай объект - как замшелые старички учили. И не дай бог перепутаешь, в стеке или в куче у тебя это храниться будет! Помню, раньше ещё, в 90-х объясняли, что у стека и кучи разная производительсноть, и надо там всё тонко разбирать. С тех пор у памяти настолько возросла производительность, а объёмы настолько увеличились, что прежняя оперативка влезает в сегодняший процессорный кеш. Да и компиляторы стали настолько умными, что аллоцируют везде, где им вздумается, и предсказать точно, где там что выделится, нельзя. Ты обозначил в коде так-то и так-то, а компилятор умнее тебя и оптимизирует как захочет. А на собесах до сих пор по языкам с неуправляемой памятью и компиляторм на ИИ гоняют по кучам и стекам.

Ни одному правилу не нужно следовать всегда и везде.

Это да. Надо руководствоваться здравым смыслом.

Примером тому goto, о котором легенды аж слагают, какой он плохой и всё такое - никогда не используйте... но есть мол пара случаев, когда он подходит. Бугага, оператор, который подходит под пару редких случаев - ради этого мы тащим его из языка в язык уже полвека.

Я не знаю случаев, когда в С# имеет смысл использовать goto. Таскают его скорее всего ради совместимости млм просто по привычке :)

Ну очевидно, я бы сказал, что возврат IEnumerable был бы лучше, т.к. можно было бы объявить общий интерфейс для квадратного уравнения, кубического, уровнения любой степени, дифференциального уравнения, системы уравнений итд. В случае с кортежем такой гибкости нет.

- Чем ты занимался последнюю неделю?

- Делал иерархическую систему интерфейсов для разных возвратов для решения разных типов уравнений. Нам нужно ещё 3 недели, чтобы дописать, отладить, и написать к этому документацию и тесты.

- *********************************************!!!!!!1111

- Ну ведь с кортежем такой гибкости нет!

))))

Не совсем понял, что ты тут предлагаешь и зачем такая функция может понадобиться, когда есть DateTime, а расчет KW можно прикрутить exstension методом. Собственно говоря, решение вычислась две разных задачи в одной функции - не самое лучше решения с точки зрения дизайна ;)

Одна или две задачи решаются вот этой конкретной функцией? Это философский вопрос, а кортеж можно заюзать здесь и сейчас.

Это было бы смешно, если бы не было бы так глупо :)

Интерфейс - это абстракция. Кортеж - конкретика.

Если разрабатывать софт опираясь на конкретные объекты, то рано или поздно будешь похоронен в лесу костылей. При этом костыли будут непонятным образом влиять друг на друга и все это это будет совершенно нетестируемо.

а кортеж можно заюзать здесь и сейчас.

Этот подход называется "хуяк, хуяк и в продакшен". Хорошего в этом мало ;)

Расскажи это своему заказчику

Без проблем. Задача импорт из текстового файла. А заказчик переименовал вордовский бинарный файл в текстовой и запустил импорт. И ждет Он будет очен рад протоколу ошибок

Я не знаю как оно там в вебе, а у меня на работе среда разработки Visual Studio 2015 и .Net 4.0. И переход на более новую версию дот нета максимально оттягивается.
Да и вообще, в реальной жизни приходится больше работать с легаси кодом, чем писать что-то новое.

Это понятно. Но эти кортежи в возврате вместо аут-параметров - это прям ням-ням. Не знаю почему, но меня постоянно бесило после названия функции вспоминать, что там надо пачку аутов определить, прерывать ход своих мыслей по коду и идти определять эти ауты. Ну это примерно как если бы уборщица во время погружения в код попросила тебя выйти на минутку, пока она под тобой пол помоет. Только уборщица делает это от силы раз в неделю, а аут-параметры - постоянно.

Юнит-тест это метод, который проверяет условия. Мы что то делаем, потом проверяем результат сделанного. Цель - проверить написанный КОД. Юниттесты проверять не надо. Они испольняются каждай раз на бильдсервере и гарантируют соответствие кода определенным критериям. Не правильности кода, а именно соответствии критериям, установленным автором тестов.

Да идея-то юнит тестов понятна. Они должны быть простыми, чтобы в них самих как можно меньше ошибок было. Но кто будет следить за тем, что они на самом деле что-то проверяют, что задача не изменилась? У тебя был один код, соответствующий заданию, теперь их параллельных два - и каждый описывает одно и то же задание, но теперь ещё первый описывает второй. При этом первый никто не описывает. Не кажется, что тут лишнее звено? В разработке через тестирование вроде как уходят от этого - там код подчиняется юнит тестам, тесты - заданию. Сам код заданию не подчиняется. Но сложность в том, что тогда тесты должны 100% или очень близко к этому покрывать код. Если нет - то снова получается, что в каких-то местах код должен подчиняться заданию, но тесты это не проверяют.

Проблема юнит тестов в том, что либо их мало и они тестируют всякую мелочную чушь, которая и так очевидна, либо их должно быть настолько много, чтобы они всё покрывали, но тогда разработка усложняется раза в два. Промежуточный вариант самый плохой - весь код не покрыт, разраб то по тестам проверяет свой код, то соотносится с заданием, то и то и другое вместе. Тогда разработка тормозится раза уже в три.

Ну очевидно, я бы сказал, что возврат IEnumerable был бы лучше,

тут ты прав, т.к. корни уравнения одного типа и порядок вывода не имеет значения.

Не совсем понял, что ты тут предлагаешь и зачем такая функция может понадобиться, когда есть DateTime, а расчет KW можно прикрутить exstension методом. Собственно говоря, решение вычислась две разных задачи в одной функции - не самое лучше решения с точки зрения дизайна ;)

DateTime не высчитывает немецкую календарную неделю.
а в алгоритме расчёта ты получаешь и неделю и год.
можно конечно написать две функции, но это во-первых копипаста будет и во-вторых не перфомантно.

Мат.часть учи - разрешили уже инлайн декларацию оут-параметрa...

Т.е. его можно использовать после вызова метода, не объявляя перед? Здорово, теперь я должен помнить, что область видимости параметров метода не всегда ограничивается этим методом. Если они инлайн-аут, то и продолжается после, а если рев - то контекст метода и вызывающий этот метод контекст.

От таких дырявых абстракций проще отказаться. Поэтому методы в шарпе - это не классические функции, как учили в начальных си-подобных языках. Раз у нас области видимости параметров играют как хотят, в зависимости от приписываемых параметрам модификаторов, то и с возвратом можно поизвращаться - гулять так гулять.

Не смешно. Особенно, когда ты рассказываешь, что пишешь софт для производства. int.Parse кидает не только FormatException. Если у тебя входная строка null (а ты, я вижу любишь возвращать null'ы), то твой подход просто проглотит исключение и будешь ты долго и упорно искать причину проблемы, которая лежит за пределами int.Parse

))))