Помощники на каждый день

[@yarosroman]

А чем String.Join хуже вашего велосипеда?

[@Vadem]

Тоже возни такой вопрос.
Неужели такой код:

  var s = string.Join(" ", "Числа", 1, 2, 3) + 
   " (" + string.Join(", ", 1, 2, 3) + ")";
  Trace.WriteLine(s);

хуже чем:

  var sm = SM.New+"Числа"-1-2-3;
  var rr = new int[] { 1, 2, 3 }; 
  sm = sm+" ("+rr.Sep(", ")+')';
  Trace.WriteLine(sm);

[@AmirYantimirov]

В строке

var sm = SM.New+"Числа"-1-2-3;

не используются скобки и запятые, экономятся нажатия пальцев!

[@denismaster]

Зато уменьшается читабельность. Сходу и не поймешь, что тут и операторы перегружены, и как они работают.

[@yarosroman]

кстати String.Join находится в mscorelib, и вы думаете изначально нативный оптимизированный код медленнее вашего велосипеда?

[@yarosroman]

Вы это серьезно? ради интереса производительность замерьте, вашего и стандартного.

[@AgentFire]

Надо писать String.Join. В C# 6 сделали возможность писать using System.String, спасибо, но поздно.

[@KvanTTT]

Вот только не using System.String, а using static System.String. У автора в статье такая же ошибка: using static System.Math.

[@AgentFire]

Все равно очень поздно!

[@yarosroman]

Чем поздно, вы тоже поклонник велосипедов и костылей как автор?

[@AgentFire]

Шутка же.

[@yarosroman]

Табличку «Сарказм» забыли, ибо тут топикстартер с такой серьезностью говорит за экономию нажатий пальцев, даже путаешь, где серьезно, а где нет

[@lair]

Спасибо, но поздно.

Не "поздно", а самое время выкинуть велосипеды, упрощая код.

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

TPL, Rx.net?

public static class IEnumerableExtensions {
    public static IEnumerable Sep(this IEnumerable objects, object separator) {
      bool first = true;
      foreach (var obj in objects) {
        if (first) first = false;
        else yield return separator;
        yield return obj;
      }
      yield break;
    }
  }

  var rr = new int[] { 1, 2, 3 }; 
  rr.Sep(", ")

Здравствуй, боксинг.

[@shai_hulud]

Про string.Join уже написали.
Велосипед с TimerTask заменяется на

async Task Start() {
      await Task.Delay(100500);
      Title = "Starting 1";
      await Task.Delay(1000);
      Starting1();
      await Task.Delay(1000);
      ///...
}

Да еще и с поддержкой отмены через CancellationToken. И даже можно сделать опрашивающий прогресс бар.

async Task Start() {
      while(!isDone)
     {
            UpdateProgressBar();
            await Task.Delay(1000)
     }
}

IntRangeNotifyCollection — прямо помощник на каждый день.

[@vdasus]

Мне вообще непонятно вот это «Спасибо, но поздно»… Что значит поздно? Давайте и async \ await не использовать — поздно же.

[@AmirYantimirov]

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

[@vdasus]

Избавление от велосипедов, которые полностью покрываются нативными средствами языка (платфомы) это очень веский повод. Мы, конечно, говорим о новых проектах, а не о переписывании существующих. Там надо отдельно анализировать. Но начинать новые продукты с велосипедом, который реализован нативно — имхо неразумно.

Если мне приходится обращаться к старым проектам и это разумно — первое что я делаю — быстренько пробегаюсь и заменяю вещи по подсказкам решарпера (типа «В C# 6 появилась возможность вписывать аргументы внутрь строки»). Это недолго даже на больших проектах. Или .? Или nameof,… да многое. Код становится читабельнее, что есть просто великолепно.

Старый код? Ок. Нельзя проапгрейдить? Ок. Но «спасибо поздно» — это… неразумно, имхо.

[@yarosroman]

А наличие велосипеда, веская причина им пользоваться? Вам знакомо слово рефакторинг?

[@shai_hulud]

На всякий случай пиарну свой пакет с велосипедом «на каждый день»
Kонвертация из А -> B одним методом. Конвертер сам «находит» подходящий способ конвертации и дергает его.

[@fedorro]

Спасибо, но

всё это уже поддерживается средствами языка, работает быстрее и часто выглядит более читаемо…

[@ink-shtil]

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

var fixedValue = badValue.Limit(MinVal, MaxVal);

Само наличие этого простого в использовании метода может породить вторую проблему — костыли.

[@sand14]

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

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

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

[@sand14]

И еще один момент: как при работе в команде вы будете убеждать участников пользоваться своими велосипедами?
А что, если у других тоже есть свои велоcипеды?

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

[@sand14]

Приведенные велосипеды во многом еще и являются образчиками «как не надо делать».

Например:

public static SM New { get { return new SM(); } }

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

В вашем случае нужно не свойство SM New, а метод SM New(), или — зачем метод? — чем не подходит создание объекта через конструктор — new SM()?

Рекомендую почитать Рихтера и ознакомиться с различными best practices для C#.
А то вы не только создаете велосипеды, но и еще и пытаетесь натянуть на C# синтаксис и подходы/практики языков, с которыми раньше работали.

Вопрос на засыпку:
как нужно доработать StringMaker, чтобы он мог форматировать строки не только в текущей культуре? с учетом того, что не все объекты, которые вы добавляете в SM, могут поддерживать форматирование с учетом культуры.

[@yarosroman]

Метод это же писать аж целых две скобки, а через конструктор, это еще и new писать.

[@AmirYantimirov]

Именно так. На C++ это был макрос, просто 'SM'.

[@yarosroman]

Вы вообще не понимаете, что это плохо? производительность, плохой стиль, нарушение правил перегрузки операторов, просто ради меньше писать? Или вы табличку сарказм забыли. Вы по минусам это не поняли? Переименуйте статью, как не надо писать на С#. будет ближе к истине.

[@ApeCoder]

он и так написал new. Только два раза — сначала в определении метода. Скобку надо писать одну — Вторую IDE дописывает :)

[@dmitry_dvm]

А почему у вас класс именуется как интерфейс? Не по канонам.