Никакой код с реф/аут отбракован не был, его утвердил тимлид.
Сабж не любит напарник, ревьюят оба.
Напарник внятно объяснить свою нелюбовь не смог, поэтому я попросил помощь зала, поскольку в голову никогда не приходило страдать такими вопросами.

stenfordесли у тебя постоянно используется ref/out/Tuple в коде - то точно что-то не то в консерватории, скорее всего очень непродуманная структура кода и классов, методы делающие и возвращающие несвязанные вещи.В консерватории очень много чего не так. Например, провайдер данных может зависеть от потребителя.)
Не я эту консерваторию запиливал.

И "постоянство" тут относительное. Я использую сабж редко, но каждый раз, как использую, получаю замечание и требование переписать. Иногда переписываю, иногда отстаиваю ref/out, если вижу, что альтернативные варианты чреваты кучей декоративного говнокода, который даже не будет повторно использован.
stenfordТакой код невозможно нормально читать и сопровождать.Некоторые куски я переписываю декларативно на linq, даже не пытаясь разобраться, как исходное говно работает.

ViPRosAntonariy... на linq, даже не пытаясь разобраться, как исходное говно работает.
лучше чем linq - стопудово"лучше" - характеристика качественная, ничего не говорящая о предмете конкретно.

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

fkthatAntonariyрешения с linq обычно работают медленнее
В общем-то, только из-за доп. расходов на компиляцию лямбд (я и тут даже не уверен, м.б. в случае LINQ to Objects это уже компилятор заранее делает - надо будет декомпилятором как-нибудь посмотреть) - других причин я придумать не могу - внутри будет такой же foreach.Замедление не от самого linq, а от обвеса, с которым он работает.

А обвес работает с экселем) Поэтому шаг влево, шаг вправо от идеального по быстродействию способа - и эксель провисает.

fkthatAntonariyА обвес работает с экселем) Поэтому шаг влево, шаг вправо от идеального по быстродействию способа - и эксель провисает.

Если с екселем работаешь через COM, то там накладные расходы на его вызовы такие, что все остальное вообще никак влиять не должно.А от COM никуда не денешься, виндовый офис имеет его в своем фундаменте. Работаю через NET-обертки ExcelDna+NetOffice, так что добавь еще накладные расходы внутри них. Однако даже их сумма ничто по сравнению с производительностью самих вызываемых методов.

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

fkthatЕвгенийВ,

Инструкций больше, это-то и так понятно, но, именно принципиальной разницы, как, например "раннее связывание" и "позднее связывание" тут нет. И там и там метод прямо по указателю вызывается.так-то ранее связывание отличается от позднего тем, что во втором как раз и есть больше инструкций, занимающимися тем, чем при раннем связывании занимается компилятор - определением адреса вызываемого метода)