Сообщение Re[4]: Проект утилитной библиотечки от 16.03.2016 6:11
Изменено 16.03.2016 6:43 Sinix
Здравствуйте, AndrewVK, Вы писали:
S>>2. Ассерты ala Code.NotNull(someValue, "someValue");
AVK>Типа шоткатов ддля Debug.Assert или что там внутри?Бросание исключения + обязательное прерывание выполнения на сработавшем ассерте (не внутри него), если подключен отладчик.
Отличная штука длядоведения до бешенства гарантии, что на ошибку не забьют. Оно работает, проверено
Вот тут было http://rsdn.ru/forum/dotnet/6068667.1
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 — по-хорошему нужны, надо определиться с языком комментариев.
S>>2. Ассерты ala Code.NotNull(someValue, "someValue");
AVK>Типа шоткатов ддля Debug.Assert или что там внутри?Бросание исключения + обязательное прерывание выполнения на сработавшем ассерте (не внутри него), если подключен отладчик.
Отличная штука для
Вот тут было http://rsdn.ru/forum/dotnet/6068667.1
Автор: Sinix
Дата: 04.06.15
Дата: 04.06.15
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 — по-хорошему нужны, надо определиться с языком комментариев.
Re[4]: Проект утилитной библиотечки
Здравствуйте, AndrewVK, Вы писали:
S>>2. Ассерты ala Code.NotNull(someValue, "someValue");
AVK>Типа шоткатов ддля Debug.Assert или что там внутри?\
Бросание исключения + обязательное прерывание выполнения на сработавшем ассерте (не внутри него), если подключен отладчик.
Отличная штука длядоведения до бешенства гарантии, что на ошибку не забьют. Оно работает, проверено
Вот тут было http://rsdn.ru/forum/dotnet/6068667.1
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.
S>>2. Ассерты ala Code.NotNull(someValue, "someValue");
AVK>Типа шоткатов ддля Debug.Assert или что там внутри?\
Бросание исключения + обязательное прерывание выполнения на сработавшем ассерте (не внутри него), если подключен отладчик.
Отличная штука для
Вот тут было http://rsdn.ru/forum/dotnet/6068667.1
Автор: Sinix
Дата: 04.06.15
Дата: 04.06.15
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.