Использование проверок на Null, нужно стараться вообще исключить из кода. Не передавать ни в качестве аргумента в методы ни ожидать в параметрах конструктора. Если такое случается это повод задуматься об дизаине кода. Скорее всего проблема в нём.
Эта фраза полностью самодостаточно, все остальное после нее — лишнее.
Сама библиотека должна быть написана так, чтобы это было ОЧЕВИДНО, когда можно послать null, а когда нет,
Но почему-то минусаторы не удосаживаются объяснить причину своего недовольства, видимо, любят тратить время на кучу проверок входных параметров у каждого метода своих классов.
Имхо, такой подход гораздо лучше. Разработчик ХОРОШЕЙ библиотеки не станет заморачиваться проверкой каждого угла на наличие null'ов. Его задача — правильно составить документацию, а в идеале — даже без нее, чтобы из названий классов и методов было ОЧЕВИДНО, возможен ли тут null или нет. А задача не пускать нулл должна быть на плечах пользователя библиотеки.
Ну, CheckForNull можно переименовать в ThrowIfNull, это не проблема, да и названия-то у методов одни и те же, следовательно, IntelliSense перегружен точно не будет.
Не очень правильные варианты голосования. Есть две абсолютно разные стези программирования — это когда пишешь код сам, и когда пишешь его с кем-то. В первом случае даже никакая проверка не нужна — если ты хорошо себя знаешь, то в 100% случаях не пошлешь null там, где его не должно быть. Во втором случае ситуация меняется, т. к. мозги другого человека — другие, и здесь можно использовать Guard, но только как "сокращатор" с двух строк на одну.
Эта фраза полностью самодостаточно, все остальное после нее — лишнее.
Сама библиотека должна быть написана так, чтобы это было ОЧЕВИДНО, когда можно послать null, а когда нет,
Но почему-то минусаторы не удосаживаются объяснить причину своего недовольства, видимо, любят тратить время на кучу проверок входных параметров у каждого метода своих классов.
Сама библиотека должна быть написана так, чтобы это было ОЧЕВИДНО, когда можно послать null, а когда нет.
Имхо, такой подход гораздо лучше. Разработчик ХОРОШЕЙ библиотеки не станет заморачиваться проверкой каждого угла на наличие null'ов. Его задача — правильно составить документацию, а в идеале — даже без нее, чтобы из названий классов и методов было ОЧЕВИДНО, возможен ли тут null или нет. А задача не пускать нулл должна быть на плечах пользователя библиотеки.
Только если эта библиотека плнируется к использованию ну совсем новичками
Там вообще жесть :)
Динамичный метод не быстрее ли будет?
"биндинг" быстрее
Есть один пакет, имхо, как раз для удобства создания конвертеров, там всего 2 женерик абстрактных класса, но с ними гораздо удобнее, чем IValueConverter каждый раз реализовывать: https://www.nuget.org/packages/AgentFire.Wpf.ValueConverters/
Ну,
CheckForNullможно переименовать вThrowIfNull, это не проблема, да и названия-то у методов одни и те же, следовательно, IntelliSense перегружен точно не будет.Не очень правильные варианты голосования. Есть две абсолютно разные стези программирования — это когда пишешь код сам, и когда пишешь его с кем-то. В первом случае даже никакая проверка не нужна — если ты хорошо себя знаешь, то в 100% случаях не пошлешь null там, где его не должно быть. Во втором случае ситуация меняется, т. к. мозги другого человека — другие, и здесь можно использовать
Guard, но только как "сокращатор" с двух строк на одну.Без скринов ну совсем как-то тускло.
Шутка же.
Все равно очень поздно!
Весьма и весьма недурно. С нетерпением жду продолжения.
Надо писать
String.Join. В C# 6 сделали возможность писатьusing System.String, спасибо, но поздно.