Здравствуйте, AndrewVK, Вы писали:
S>>4. Соглашения по оформлению кода — стандартные дотнетовские AVK>Единственные потенциальные проблемы — 4 пробела в качестве отступа и s_ префикс у статиков.
Ну да, поэтому и не настаиваю.
Главное, чтоб было
S>>5. Threat warnings as errors. AVK>Это уже перебор.
Вот я сейчас работаю на проекте, на котором это не было сделано с самого начала. С варнингами в итоге никто не борется, потому что они есть даже в автосгенерированном коде. Количество сам можешь представить.
Поэтому только как errors, подавлять прагмой — её хоть найти можно.
S>>6. XML comments — по-хорошему нужны, надо определиться с языком комментариев. AVK>Английский, разумеется.
Ок
UPD
7. Нужно с самого начала определиться с тестами. Предлагаю требовать только тесты с сценариями использования, складывать их в отдельную папку (UseCases и назвать), остальное — добровольное, в папку Tests.
Тесты — любые, которые поддерживает appveyor, я бы взял xUnit, хотя бы из-за xBehave или fixie.
AVK>Из того что лично у меня часто используется в разных проектах: AVK>1) Инфиксные формы string.Format, IsNull, IsNullOrWS, Join. AVK>2) Упрощение работы с XDocument — доступ к элементам с проверкой на Null или существование, типизированное чтение атрибутов и т.п. AVK>3) Некоторое количество хелперов для рефлекшена — получение текущей сборки, доступ к ресурсу с проверкой наличия, типизированное чтение атрибутов, создание экземпляра объекта по типу со всякими фенечками и проверками. AVK>4) Хелперы для коллекций и линка. Там много разного. Например Concat у которого в параметрах не коллекция, а единичный элемент или метод FirstOrValue. AVK>5) Хелпер для сравнения текстовых дампов — полезно при написании тестов. AVK>6) Словарик с ленивой инициализацией элементов. Что то вроде гибрида Dictionary и Lazy. AVK>7) Хелпер, обеспечивающий использование ReaderWriterLock с оператором using. AVK>8) Хелпер для получения пустых массивов без лишних экземпляров.
А это все планируется как единая библиотека (1 пакет NuGet) или же с разделением по темам (ну там lib.Strings , lib.XDoc и т.д.)
Так же для какого .NET это все планируется делать (или для каких). Я как про мин. версию, так и тип.
Здравствуйте, Sinix, Вы писали:
S>3. Студия 2015, таргетинг на 4.5. Проекты должны открываться и в 2012/2013, т.е. с совместимостью проблем не будет. На кросплатформенность я бы сейчас не замахивался. Хотя я бы переключился на 4.5.2 как минимум.
4.5.2 как минимально поддерживаемый это мне кажется разумным. Но вот не ограничит ли это область использования?
Плюс зачем игнорить Core? Как по мне, лучше уже что-то исключить из сборки под Core (если что сейчас не поддерживается), чем потом допиливать и тестить все. Отсюда же и для unit test использовать xUnit.
Здравствуйте, Shmj, Вы писали:
S>Имх, долно начинаться с .Net или N. Сразу видна таргетизация.
Это чисто явовские заморочки. Для дотнета принято соглашение Бренд.ЧтоДелает.
Здравствуйте, Doc, Вы писали:
Doc>А это все планируется как единая библиотека (1 пакет NuGet) или же с разделением по темам (ну там lib.Strings , lib.XDoc и т.д.)
Думаю, на первом этапе лучше один пакет. Точнее два — основной функционал и экспериментальный. В дальнейшем можно и порезать на куски, только, конечно, не настолько мелкие.
Doc>Так же для какого .NET это все планируется делать (или для каких). Я как про мин. версию, так и тип.
Да, тут вопрос, на который лично у меня нет ответов. Есть .NET, .NET Core, WinPhone, Xamarin (Silverlight, слава богу, помер). Но в этой области у меня опыта мало.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Doc, Вы писали:
Doc>4.5.2 как минимально поддерживаемый это мне кажется разумным. Но вот не ограничит ли это область использования?
Ну можно на 4 откатить, если желающие будут. Не ниже уж точно.
Doc>Плюс зачем игнорить Core? Как по мне, лучше уже что-то исключить из сборки под Core (если что сейчас не поддерживается), чем потом допиливать и тестить все. Отсюда же и для unit test использовать xUnit.
Боюсь я сечас закладываться на кроссплатформенные нюгет-пакеты. Там очередная революция с .platform standard грядёт.
Ну т.е. можно, но нужен доброволец, кто будет оперативно приводить пакеты к актуальному виду.
Здравствуйте, AndrewVK, Вы писали:
Doc>>Плюс зачем игнорить Core? AVK>Ну, у меня нет опыта совсем с этим делом. Если у тебя есть опыт и желание — можно и не игнорить.
Ну вот подумываю, что можно и присоединиться.
AVK>Связь с xUnit не очень понятна.
Здравствуйте, AndrewVK, Вы писали:
AVK>Кто планирует активно участвовать — кидайте логины на гитхабе, добавлю права чтобы не тратить время на пулреквесты. AVK>И нужен человек, способный без косяков написать readme.md с основной идеологией.
Здравствуйте, AndrewVK, Вы писали:
AVK>Кто планирует активно участвовать — кидайте логины на гитхабе, добавлю права чтобы не тратить время на пулреквесты.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, AndrewVK, Вы писали:
AVK>>Есть более специфичные штуки — парсер командной строки, парсер CSV, но тут уже я не уверен в уместности такого. S>Могу докинуть: S>1. Методы NotNullOrEmpty() для строк и для enumerable. Разница такая же как с Any()/All() — одно можно выразить через другое, но читаемость страдает. S>2. Ассерты ala Code.NotNull(someValue, "someValue"); S>3. GetOrAdd() + AddOrUpdate() для словарей. S>4. Хелперы для enum-ов — проверка на флаги etc. С нормальной производительностью, а не как у Enum.HasFlag() S>5. Factory для Disposable, using(Disposable.Create(()=>OnDispose())) { }
S>Если кому надо — Range<T>/CompositeRange<T> для операция над диапазонами/наборами диапазонов — объединение, пересечение, дополнение — полный набор.
S>Может ещё что полезного было, пожже напишу.
"Методы NotNullOrEmpty() для строк" — как это работает?
Название мягко говоря противоречивое
Все варианты делают одно и то же, но вариант D самый читабельный, т.к. во-первых не требует скакать взглядом назад, во-вторых, не путается с IsNullOrEmpty() как C.
В общем я на эти грабли за 10 лет понаступал, больше не тянет.
