_>>2. clipboardDataUpdater — вызывается в конце кода! Проще чтобы SetData вернул что надо, а делегат вызвать следом.

НС>При этом потеряется ленивость, это может быть важно.

Ленивость? )). Круто. А я думал ленивость в том чтобы бред не писать на пустом месте.
С ленивостью просто не вызываете clipboardDataUpdater следом.

Здравствуйте, okon, Вы писали:

_>>Да не, ну этот метод считают крайне полезным, его в библиотеку тянут ).
_>>Хрен с ним коллегой, мне за такую библиотеку стыдно.

O>Тут по идее в первую очередь должно быть стыдно не за библиотеку, а за такие отношения с коллегами

Я полагаю мы инженеры, и должны обсуждать код. Оставьте отношения психологам

Здравствуйте, okon, Вы писали:

O>Здравствуйте, barn_czn, Вы писали:

_>>Хелп! Объясните мне люди, я чего то не понимаю в этом мире.

_>>Код ниже я считаю откровенным гвнокодом. Не могу никак доказать коллеге что это так.

O>Вполне гибко сделано, да читается чуть хуже.

Аа, гибко.. ну замените в 3х строчках методы А и Б на другие, получите снова гибкость. А ведь таких пар методов, которые обычно друг за другом вызываются ох как много. И что теперь надо наклепать этот гибкий код на каждую пару?
Люди, вы в своем уме? Вы считаете просто пара методов А и Б сложнее вот этого гибкого кода?

Ну и наконец базовое мое утверждение: ни надо передавать делегат если он вызывается в конце метода. Потому что вызвать нечто в конце метода равносильно вызову после самого метода.

Здравствуйте, RushDevion, Вы писали:


RD>Мне этот код не нравится прежде всего тем, что глядя на контракт функции
RD>

void SetData(Action<DataObject, Action> clipboardDataUpdater);

RD>совершенно неясно, как этим правильно пользоваться.

Дело ни в типизированом контракте. Хотя согласен, в таких случаях не мешало бы.
Мое утверждение: ни надо передавать делегат если он вызывается в конце метода. Это равносильно тому чтобы самому вызывать делегат после вызова метода.

Если уж говорить о преобразовании этого кода то я выберу такое:

public static Action SetData()
{
 Clipboard.Clear();
 var data = new DataObject();
 return () => Clipboard.SetDataObject(data, true);
}

Утверждаю что эта форма метода ни теряет того что было. Но и это гвнокод, все потому же: на 3 строчки кода наводим магию делегатов.

Здравствуйте, barn_czn, Вы писали:

_>Здравствуйте, okon, Вы писали:

_>>>Да не, ну этот метод считают крайне полезным, его в библиотеку тянут ).
_>>>Хрен с ним коллегой, мне за такую библиотеку стыдно.

O>>Тут по идее в первую очередь должно быть стыдно не за библиотеку, а за такие отношения с коллегами

_>Я полагаю мы инженеры, и должны обсуждать код. Оставьте отношения психологам
Не только инженеры, но и люди, которым важна в том числе определенная культура.
Вы же не ходите под стол на работе, оправдываясь тем — потому что я инженер.
Оставаться человеком, это важнее.

_>Ну и наконец базовое мое утверждение: ни надо передавать делегат если он вызывается в конце метода. Потому что вызвать нечто в конце метода равносильно вызову после самого метода.
Не равносильно.
Попробуй варианты которые я привел выше реализовать при таком подходе.

Здравствуйте, barn_czn, Вы писали:

_>Хелп! Объясните мне люди, я чего то не понимаю в этом мире.

Зачем второй Action для меня очевидно, но я много Desktop систем писал. Это что бы оптимизировать логику (и простоту и производительность) в фоновых потоках.

А зачем первый я хз — наверно от незнания, чиста по аналогии с первым.

Здравствуйте, barn_czn, Вы писали:

_>С ленивостью просто не вызываете clipboardDataUpdater следом.

А если решение должно приниматься в обработчике? А если нужна синхронизация в винформсах/wpf?

Здравствуйте, barn_czn, Вы писали:

_>Я полагаю мы инженеры, и должны обсуждать код. Оставьте отношения психологам

Код, при условии полного отсутствия контекста, вполне нормальный. То что у тебя некоторые трудности с функциональным стилем — то не повод коллегу обвинять, а повод расширить собственные навыки.

Здравствуйте, barn_czn, Вы писали:

_>

_>/// <summary>
_>/// Clear and places a specified data on the system Clipboard and accepts updater for additional clipboard updating.
_>/// </summary>
_>/// <param name="clipboardDataUpdater">The clipboard data updater.</param>
_>/// <exception cref="ArgumentNullException">clipboardDataUpdater</exception>
_>public static void SetData(Action<DataObject, Action> clipboardDataUpdater)
_>{
_>    if (clipboardDataUpdater == null)
_>    {
_>        throw new ArgumentNullException(nameof(clipboardDataUpdater));
_>    }

_>    Clipboard.Clear();
_>    var data = new DataObject();

_>    clipboardDataUpdater(data, () => Clipboard.SetDataObject(data, true));
_>}
_>

Говнокод.
1) Clears and places a specified data on the system Clipboard
На самом деле ничего он не "places", а отдает лямбду в сторонний код, который может быть ее выполнит. А может и нет.
2) clipboardDataUpdater на самом деле ничего не знает про clipboard. Это просто dataUpdater. Это запутывает и явно говорит о том, что писавший код тоже плохо понимал что происходит.
3) clipboardDataUpdater никуда явно не передает результат своей работы. В вызываемую лямбду он через замыкание попадает. Это работает, но говнокод. У кода должны быть ясные и понятные намерения.
4) Возможна ситуация, когда SetData просто очистил буфер но ничего туда не просетил. С именем метода это плохо сочетается. Set обычно подразумевает атомарную операцию.

У нас бы кодревью это не прошло.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, barn_czn, Вы писали:

_>>Я полагаю мы инженеры, и должны обсуждать код. Оставьте отношения психологам

НС>Код, при условии полного отсутствия контекста, вполне нормальный.

Вообщето на то и разделение на методы, классы, чтобы вне контекста код говорил сам за себя. Да и какой контекст может быть когда это статик метод некоторого статик хелпера.
Модификатор static тебе должен что то сказать или не?

>То что у тебя некоторые трудности с функциональным стилем

Трудности у тебя похоже. На код то посмотри еще раз, переданный делегат вызывается в конце метода. Нигде ни йокнуло?
Я прекрасно разбираюсь в ФП, монадах и прочем. ФП — инструмент, а ни повод на пустом месте городить огороды.

Здравствуйте, okon, Вы писали:

_>>Ну и наконец базовое мое утверждение: ни надо передавать делегат если он вызывается в конце метода. Потому что вызвать нечто в конце метода равносильно вызову после самого метода.
O>Не равносильно.
O>Попробуй варианты которые я привел выше реализовать при таком подходе.

Причем тут твои варианты? Я обсуждаю приведенный мной код а ни твои варианты.

Мое утверждение — ну давай на пальцах, раз так ни очевидно:

public static void Do(Action externalDo)
{
    //any any
    externalDo();
}

Использование:

Do(myDo);

Вариант без делегата:

public static void Do()
{
    //any any    
}

Использование:

Do();
myDo();

Утверждение доказано.

Здравствуйте, barn_czn, Вы писали:

НС>>Код, при условии полного отсутствия контекста, вполне нормальный.
_>Вообщето на то и разделение на методы, классы, чтобы вне контекста код говорил сам за себя.

Нет, не на то.

_> Да и какой контекст может быть когда это статик метод некоторого статик хелпера.

Обычный. То как этот метод используется и какую задачу решает.

>>То что у тебя некоторые трудности с функциональным стилем
_>Трудности у тебя похоже.

Угу, сам дурак.

_> На код то посмотри еще раз, переданный делегат вызывается в конце метода. Нигде ни йокнуло?

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

_>Я прекрасно разбираюсь в ФП, монадах и прочем.

Даже не спорю, что разбираешься. Но не я тут написал про вынос мозга от коротенького простого кусочка.

Здравствуйте, barn_czn, Вы писали:

_>Причем тут твои варианты? Я обсуждаю приведенный мной код а ни твои варианты.

С приведенным тобой кодом такое тоже возможно:

SetData((do, commit) =>
{
  DoSmth();
  SynchronizationContext.Current.Send(commit);
})

Или

SetData((do, commit) =>
{
  DoSmth();
  ThreadPool.QueueUserWorkItem(s =>
  {
    DoSmthElse();
    commit();
  });
})

_>> На код то посмотри еще раз, переданный делегат вызывается в конце метода. Нигде ни йокнуло?

НС>Нет. Делегат, который нужно дернуть при завершении обработки — довольно часто встречающееся явление в случае, когда прямой поток управления по каким то причинам невозможен.

Бинго, еще раз смотрим на код. Это ни прямой поток управления? Где тут ни прямо? Может тебя if сбило с толку? Ну тогда давай убедимся, что если даже зайдет в if то код все равно эквивалентен тому как если бы делегат не передавать во внутрь а выполнить потом. Почему? да потому что внутри if кидание эксепшена который все равно прерывает прямой поток управления.

_>>Я прекрасно разбираюсь в ФП, монадах и прочем.

НС>Даже не спорю, что разбираешься. Но не я тут написал про вынос мозга от коротенького простого кусочка.

Если задача сделать простое сложным — то да, этот метод этого добился. Вынос мозга как раз в том что простое сделано сложнее. А ни в том что я этот код не понял. Ну это если ты в словоблудие не кинулся сейчас.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, barn_czn, Вы писали:

_>>Причем тут твои варианты? Я обсуждаю приведенный мной код а ни твои варианты.

НС>С приведенным тобой кодом такое тоже возможно:

Такое это какое? Алее мы о чем?

Здравствуйте, barn_czn, Вы писали:

_>Бинго, еще раз смотрим на код. Это ни прямой поток управления?

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

_>>>Я прекрасно разбираюсь в ФП, монадах и прочем.
НС>>Даже не спорю, что разбираешься. Но не я тут написал про вынос мозга от коротенького простого кусочка.
_>Если задача сделать простое сложным — то да, этот метод этого добился.

Я не вижу пока никакой задачи вообще, вижу только короткий кусок кода с непонятным назначением.

Здравствуйте, barn_czn, Вы писали:

НС>>С приведенным тобой кодом такое тоже возможно:
_>Такое это какое? Алее мы о чем?

О том что при подобном использовании дизайн с делегатом вполне оправдан.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, barn_czn, Вы писали:

НС>>>С приведенным тобой кодом такое тоже возможно:
_>>Такое это какое? Алее мы о чем?

НС>О том что при подобном использовании дизайн с делегатом вполне оправдан.

ну ты еще про пользу делегатов мне расскажи ).

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, barn_czn, Вы писали:

_>>Бинго, еще раз смотрим на код. Это ни прямой поток управления?

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

_>>>>Я прекрасно разбираюсь в ФП, монадах и прочем.
НС>>>Даже не спорю, что разбираешься. Но не я тут написал про вынос мозга от коротенького простого кусочка.
_>>Если задача сделать простое сложным — то да, этот метод этого добился.

НС>Я не вижу пока никакой задачи вообще, вижу только короткий кусок кода с непонятным назначением.



т.е. чтобы оценить код одного метода из 5 строк надо выложить назначение всей программы? прикольная логика. Ни надо, ни отвечай.