Где то на необъятных просторах России матушки открыли еще один мусорный полигон. Как тут сказали выше, неплохо было бы хотя бы как у французов ввести раздельную обработку мусора. Заголовок конечно пафосный.
Структуры данных, а не алгоритмы, играют центральную роль в программировании.
Ммм… Ну есть у вас Козлоотпущеническое само-балансирующее древо(Scapegoat tree), структура данных, а собственно на чем строится чтение и запись? На тех же алгоритмах.
Есть у нас супер структуры данных такие как графы, только грош им цена на практике без всех Дейкстр и А* алгоритмов.
Не даром например Кнут в своем "Искусстве Программирования" рассматривает алгоритмы и структуры данных неразрывно.
Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимоотношениях
Больше похоже на отмазку типа идите с вашим чистым кодом лесом и оставьте меня писать код который поймут полторы калеки на этой планете.
Это все мега относительно, структуры данных важны при написании/расширении компилятора, но не при написании какойнить Restful API средней руки. Цитата вырвана из контекста.
Та не, какая то каша получилась, автор взял да слил в одну лужу концепции Either и Railway Oriented Programming. В конце концов получилось что то нелепое. В RoP конечный продукт это продвинутая композиция функций а не непонятно что:
Я имел ввиду, что у вас метод уже создает что-то — соответственно сочетать два таких метода вместе не удастся. Метод не умеет модифицировать уже готовый ордер, например.
Да блин возможности по композиции в .NET почти безграничны, зачем вам метод createAll.
Обычно названия метода-теста выводятся при ошибках…
А ну да обрубок вроде Method_ShouldWorkAsExpected_WhenGetsRightValue заменяет полноценную фразу на человеческом языке(xUnit не в счет)
Я думаю, имелось ввиду action
Да но ваш service это объект тестирования, так что это сбивает с толку.
Возможно — но тогда придется все сочетания поддерживать в одном методе.
Ну это уж вам решать как структурировать код, можно и не в одном методе.
С моей точки зрения, когда в тесте ровно один ассерт и название достаточно говорящее, это не надо.
Здесь страдает не читаемость кода теста, а ошибки в ходе прогона тестов.
Почему?
Ну хотя бы потому что:
Секция 8.3.4 Separating asserts from actions For the sake of readability, avoid writing the assert line and the method call in the same statement.
Кстати в той же книге предлагается награждать описанием проверки типа:
Assert.Equals(AmountOfProductInOrderLine * AmountOfIngridientInProduct, service.GetReservedAmount(ingridient), "Ибо так потребно");
Не совсем уверен что service.GetReservedAmount(ingridient) и AmountOfProductInOrderLine * AmountOfIngridientInProduct уместны в секции Assert, по книге аrt of unit testing.
Вы привели достаточно простой пример строителя, но в настоящей жизни нам пришлось бы иметь дело со строителем на 3 или 4 десятка строк больше. Иметь такое чудо в коде теста, на мой взгляд, не приемлемо. Тест это не только тест, но и живая документация. Так что смысла в доморощенных строителях не вижу, тем более что с AutoFixture все можно персонализировать и если это делать то в отдельном вспомогательном методе.
// Arrange
var order = CreateDualOrder();
var service = CreatePizzeriaService();
// Act
service.AcceptOrder(order);
// Assert
service.VerifyReserveIngredientsWasCalledWith(order);
Не совсем понимаю в чем соль доморощенного DSL, зачем время тратить на классы строители? Я бы вас понял если бы вы писали в эпоху Java6 на ней самой. Классы строители как шаблон изжили себя в среде .NET.
FYI: Термин "Дженерики" на русский переводится как "Обобщения".
Асинхронные Stream в C# 8 как я понимаю не поддерживают обратного давления и для более или менее житейский ситуаций нужно использовать Rx?
Идея конечно хорошая но пока вы тут
Где то на необъятных просторах России матушки открыли еще один мусорный полигон. Как тут сказали выше, неплохо было бы хотя бы как у французов ввести раздельную обработку мусора. Заголовок конечно пафосный.
Интересно выходит, лицензию на продукты купи, потом еще на плагины раскошелся.
Ммм… Ну есть у вас Козлоотпущеническое само-балансирующее древо(Scapegoat tree), структура данных, а собственно на чем строится чтение и запись? На тех же алгоритмах.
Есть у нас супер структуры данных такие как графы, только грош им цена на практике без всех Дейкстр и А* алгоритмов.
Не даром например Кнут в своем "Искусстве Программирования" рассматривает алгоритмы и структуры данных неразрывно.
Больше похоже на отмазку типа идите с вашим чистым кодом лесом и оставьте меня писать код который поймут полторы калеки на этой планете.
Это все мега относительно, структуры данных важны при написании/расширении компилятора, но не при написании какойнить Restful API средней руки. Цитата вырвана из контекста.
Та не, какая то каша получилась, автор взял да слил в одну лужу концепции Either и Railway Oriented Programming. В конце концов получилось что то нелепое. В RoP конечный продукт это продвинутая композиция функций а не непонятно что:
Athena with Meltdown(и прочим добром) inside?
Вас понял, спасибо
Будьте так любезны, ссылочку на оригинал. Спасибо
А где же Калина Рогозина, как достойный ответ?
Дайте угадаю, это современное чудо по умолчанию с батчем запускается, PowerShell для опытных пользователей. заграждения
Да блин возможности по композиции в .NET почти безграничны, зачем вам метод createAll.
А ну да обрубок вроде
Method_ShouldWorkAsExpected_WhenGetsRightValueзаменяет полноценную фразу на человеческом языке(xUnit не в счет)Да но ваш
serviceэто объект тестирования, так что это сбивает с толку.Ну это уж вам решать как структурировать код, можно и не в одном методе.
Здесь страдает не читаемость кода теста, а ошибки в ходе прогона тестов.
Ну хотя бы потому что:
Секция 8.3.4 Separating asserts from actions
For the sake of readability, avoid writing the assert line and the method call in the same statement.
По мне так все равно куча ненужного шума:
Лучше
Кстати в той же книге предлагается награждать описанием проверки типа:
Не совсем уверен что
service.GetReservedAmount(ingridient)иAmountOfProductInOrderLine * AmountOfIngridientInProductуместны в секции Assert, по книге аrt of unit testing.Вы привели достаточно простой пример строителя, но в настоящей жизни нам пришлось бы иметь дело со строителем на 3 или 4 десятка строк больше. Иметь такое чудо в коде теста, на мой взгляд, не приемлемо. Тест это не только тест, но и живая документация. Так что смысла в доморощенных строителях не вижу, тем более что с AutoFixture все можно персонализировать и если это делать то в отдельном вспомогательном методе.
Это проект конкурент ML.NET или скорее дополнение? Это конкурент OpenCV? Данный проект сможет работать на
netcore? Спасибо.Не совсем понимаю в чем соль доморощенного DSL, зачем время тратить на классы строители? Я бы вас понял если бы вы писали в эпоху Java6 на ней самой. Классы строители как шаблон изжили себя в среде .NET.
Не совсем понятно нафиг все это надо, если есть AutoFixture.
Ну или можно просто теми же астероидами затопить всю поверхность Марса, создав там подобие водного мира.
А авто-добавление пространств имен добавили уже? Спасибо.