AmirYantimirov Oct 28 2016 at 10:03

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

6 min

6.3K

.NET*C#*Development for Windows*

From sandbox

Comments 29

yarosroman Oct 28 2016 at 10:14

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

Vadem Oct 28 2016 at 10:37

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

  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 Oct 28 2016 at 10:41

В строке

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

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

denismaster Oct 28 2016 at 10:44

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

yarosroman Oct 28 2016 at 11:05

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

yarosroman Oct 28 2016 at 10:46

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

AgentFire Oct 28 2016 at 10:42

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

KvanTTT Oct 28 2016 at 12:59

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

AgentFire Oct 29 2016 at 08:28

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

yarosroman Oct 29 2016 at 13:44

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

AgentFire Oct 29 2016 at 15:06

Шутка же.

yarosroman Oct 31 2016 at 00:28

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

lair Oct 28 2016 at 10:27

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

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

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

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 Oct 28 2016 at 10:28

Про 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 Oct 28 2016 at 10:28

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

AmirYantimirov Oct 28 2016 at 10:45

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

vdasus Oct 28 2016 at 10:54

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

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

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

yarosroman Oct 28 2016 at 11:12

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

shai_hulud Oct 28 2016 at 10:32

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

fedorro Oct 28 2016 at 12:30

Спасибо, но

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

ink-shtil Oct 29 2016 at 01:36

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

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

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

sand14 Oct 29 2016 at 01:36

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

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

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

sand14 Oct 29 2016 at 03:44

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

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

sand14 Oct 29 2016 at 04:29

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

Например:

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

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

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

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

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

yarosroman Oct 29 2016 at 07:05

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

AmirYantimirov Oct 30 2016 at 05:05

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

yarosroman Oct 30 2016 at 06:50

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

ApeCoder Oct 31 2016 at 10:51

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

dmitry_dvm Oct 29 2016 at 10:59

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