В соседнем обсуждении зашла речь о том, что у многих, если не у каждого, скопилось некоторое количество кода, который применяется в большом количестве, если не во всех проектах. В связи с чем родилась идея собрать самое интересное в опенсорсный проект и выложить нугет с библиотечкой, чтобы использовать ее, а не свои велосипеды таскать.
Основные критерии оптимизации — высокая универсальность (т.е. возможность использовать в широком спектре проектов), минимальный объем навязываемых решений (т.е. никаких сквозных подвязок, никаких фреймворков), высокая читаемость и качество кода.
Вопросы:
1) Кто что по этому думает?
2) Что бы хотелось в этой библиотеке увидеть, и что не хотелось бы?
3) Кому интересно в этом поучаствовать?
4) Кому интересно библиотеку в своих проектах использовать?
Из того что лично у меня часто используется в разных проектах:
1) Инфиксные формы string.Format, IsNull, IsNullOrWS, Join.
2) Упрощение работы с XDocument — доступ к элементам с проверкой на Null или существование, типизированное чтение атрибутов и т.п.
3) Некоторое количество хелперов для рефлекшена — получение текущей сборки, доступ к ресурсу с проверкой наличия, типизированное чтение атрибутов, создание экземпляра объекта по типу со всякими фенечками и проверками.
4) Хелперы для коллекций и линка. Там много разного. Например Concat у которого в параметрах не коллекция, а единичный элемент или метод FirstOrValue.
5) Хелпер для сравнения текстовых дампов — полезно при написании тестов.
6) Словарик с ленивой инициализацией элементов. Что то вроде гибрида Dictionary и Lazy.
7) Хелпер, обеспечивающий использование ReaderWriterLock с оператором using.
8) Хелпер для получения пустых массивов без лишних экземпляров.
Есть более специфичные штуки — парсер командной строки, парсер CSV, но тут уже я не уверен в уместности такого.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Основные критерии оптимизации — высокая универсальность (т.е. возможность использовать в широком спектре проектов), минимальный объем навязываемых решений (т.е. никаких сквозных подвязок, никаких фреймворков), высокая читаемость и качество кода.
Два варианта:
1) качество кода + поддержка + универсальность + рецензирование, как следствие высокий порог вхождения нового кода
2) свалка разрозненных компонентов + возможно нестабильное API + быстрая эволюция и т.п. — минимальный порог вхождения
Оба варианта полезны и нужны — первый ради качества, второй ради количества.
В C++ есть первый вариант — Boost. Часто не хватает второго — есть много мелких компонентов раскиданных по сети, которые по качеству не тянут на 1) но тем не менее при этом могли бы приносить бОльшую пользу будь они скомпонованы в одну библиотеку с минимальной структурой, также повысился бы их шанс роста до 1), плюс какая-никакая взаимная синергия.
Отбрасывать второй вариант думаю не стоит, может есть смысл создать два параллельных проекта?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Два варианта: EP>1) качество кода + поддержка + универсальность + рецензирование, как следствие высокий порог вхождения нового кода EP>2) свалка разрозненных компонентов + возможно нестабильное API + быстрая эволюция и т.п. — минимальный порог вхождения
EP>Оба варианта полезны и нужны — первый ради качества, второй ради количества.
Я думал именно про первый. Ну, по крайней мере мне самому как пользователю первый нужен.
EP>В C++ есть первый вариант — Boost.
Спорно. В бусте много шлака. Ну и с С++ ситуация сильно другая, не надо его практики на дотнет переносить.
EP>Отбрасывать второй вариант думаю не стоит, может есть смысл создать два параллельных проекта?
Два параллельных — перебор. Можно просто две части в рамках одного проекта. Стабильную и экспериментальную.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK>Есть более специфичные штуки — парсер командной строки, парсер CSV, но тут уже я не уверен в уместности такого.
Могу докинуть:
1. Методы NotNullOrEmpty() для строк и для enumerable. Разница такая же как с Any()/All() — одно можно выразить через другое, но читаемость страдает.
2. Ассерты ala Code.NotNull(someValue, "someValue");
3. GetOrAdd() + AddOrUpdate() для словарей.
4. Хелперы для enum-ов — проверка на флаги etc. С нормальной производительностью, а не как у Enum.HasFlag()
5. Factory для Disposable, using(Disposable.Create(()=>OnDispose())) { }
Если кому надо — Range<T>/CompositeRange<T> для операция над диапазонами/наборами диапазонов — объединение, пересечение, дополнение — полный набор.
Здравствуйте, Sinix, Вы писали:
S>1. Методы NotNullOrEmpty() для строк
Про это вроде написал.
S> и для enumerable. Разница такая же как с Any()/All() — одно можно выразить через другое, но читаемость страдает.
Да это понятно, можешь не объяснять.
S>2. Ассерты ala Code.NotNull(someValue, "someValue");
Типа шоткатов ддля Debug.Assert или что там внутри?
S>3. GetOrAdd() + AddOrUpdate() для словарей.
В ту же кучу GetValueOrDefault — out параметры не позволяют вопхнуть в выражение, а если там еще и анонимный тип, то вообще других вариантов нет.
S>4. Хелперы для enum-ов — проверка на флаги etc. С нормальной производительностью, а не как у Enum.HasFlag()
Угу. И типизированные.
S>5. Factory для Disposable, using(Disposable.Create(()=>OnDispose())) { }
Это есть в Rx, но ради одной ерунды не всегда его интересно тянуть.
S>Если кому надо — Range<T>/CompositeRange<T> для операция над диапазонами/наборами диапазонов — объединение, пересечение, дополнение — полный набор.
Ой, больной вопрос. У меня есть даже реализация таких структурок, правда не для себя — надо переписывать. Но насколько это часто нужно неясно. У меня в них хранились ренджи символов для лексера.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
EP>>В C++ есть первый вариант — Boost. AVK>Спорно. В бусте много шлака.
Например?
AVK>Ну и с С++ ситуация сильно другая,
И чем она сильно другая?
AVK>не надо его практики на дотнет переносить.
Boost это набор рецензируемых библиотек разрабатываемых сообществом, тематика самая широкая (общеязыковые компоненты типа контейнеров и алгоритмов, прикладные вещи типа Odeint, системные а-ля Asio, C++ специфичные типа Fusion) — чем это отличается от сабжа? Тематика сабжа будет уже?
EP>>Отбрасывать второй вариант думаю не стоит, может есть смысл создать два параллельных проекта? AVK>Два параллельных — перебор. Можно просто две части в рамках одного проекта. Стабильную и экспериментальную.
Да, тоже вариант, только экспериментальная часть должна быть доступна в том числе в виде пакета, должны прогоняться минимальные тесты и т.п. — то есть не просто experimental repo.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>В C++ есть первый вариант — Boost. AVK>>Спорно. В бусте много шлака. EP>Например?
Я давно уже туда не заглядывал, поэтому врать не буду.
AVK>>Ну и с С++ ситуация сильно другая, EP>И чем она сильно другая?
Крайне бедная стандартная библиотека, сам язык плохо приспособлен для написания широко используемых библиотек, много извратов с метапрограммированием на шаблонах.
EP> Тематика сабжа будет уже?
Наоборот шире. Но никаких планов по включению туда специализированных вещей типа того же spirit нет. Есть вполне конкретная потребность обобщения вещей, которые используются часто и во многих проектах, т.е. самого универсального кода. А собрать туда все подряд, да еще и с условием отсутствия каких либо сквозных структур — с какой целью? При наличии nuget все что нужно ты можешь собрать из разных библиотек, не?
EP>>>Отбрасывать второй вариант думаю не стоит, может есть смысл создать два параллельных проекта? AVK>>Два параллельных — перебор. Можно просто две части в рамках одного проекта. Стабильную и экспериментальную. EP>Да, тоже вариант, только экспериментальная часть должна быть доступна в том числе в виде пакета, должны прогоняться минимальные тесты и т.п. — то есть не просто experimental repo.
Разумеется.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
CodeJam, CodePieces, CodeShorts (добавил свой вариант: загуглил слово — посмеялся, хотя по смыслу подходит), CodeBlocks/CodeBricks(слишком баззвордово).
Здравствуйте, AndrewVK, Вы писали:
S>>2. Ассерты ala Code.NotNull(someValue, "someValue"); AVK>Типа шоткатов ддля Debug.Assert или что там внутри?\
Бросание исключения + обязательное прерывание выполнения на сработавшем ассерте (не внутри него), если подключен отладчик.
Отличная штука для доведения до бешенства гарантии, что на ошибку не забьют. Оно работает, проверено
S>>5. Factory для Disposable, using(Disposable.Create(()=>OnDispose())) { } AVK>Это есть в Rx, но ради одной ерунды не всегда его интересно тянуть.
Ну вот поэтому и предлагаю
S>>Если кому надо — Range<T>/CompositeRange<T> AVK>Ой, больной вопрос. У меня есть даже реализация таких структурок, правда не для себя — надо переписывать. Но насколько это часто нужно неясно. У меня в них хранились ренджи символов для лексера.
Значит откладываем, для начала то, что точно нужно людям берём.
Оргпредложения — стандартный набор:
1. Гитхаб + appveyor с публикацией в нюгет.
2. MIT license.
3. Студия 2015, таргетинг на 4.5. Проекты должны открываться и в 2012/2013, т.е. с совместимостью проблем не будет. На кросплатформенность я бы сейчас не замахивался. Хотя я бы переключился на 4.5.2 как минимум.
4. Соглашения по оформлению кода — стандартные дотнетовские, благо поддерживаются автоматом. Если нет — надо делать набор правил StyleCop + рекомендации как настроить какой-нить бесплатный форматтер типа CodeMaid, иначе никто их соблюдать не будет.
5. Threat warnings as errors.
6. XML comments — по-хорошему нужны, надо определиться с языком комментариев.
UPD
7. Нужно с самого начала определиться с тестами. Предлагаю требовать только тесты с сценариями использования, складывать их в отдельную папку (UseCases и назвать), остальное — добровольное, в папку Tests.
Тесты — любые, которые поддерживает appveyor, я бы взял xUnit, хотя бы из-за xBehave или fixie.
Здравствуйте, Sinix, Вы писали:
S>6. XML comments — по-хорошему нужны, надо определиться с языком комментариев.
Нужно все делать с глобальным прицелом. Зачем ограничивать себя?
Англ. не у всех хорош, по этому формируйте мысль попроще и используйте гугле-транслейт. Как минимум чтобы не было орфографических ошибок и смысл можно было уловить. Позже выделить день и сделать найтивную вычитку.
Если нам не помогут, то мы тоже никого не пощадим.
