Здравствуйте, AndrewVK, Вы писали:
AVK>И? Разве правильно так реагировать на пробелы?
Тут имхо вопрос не в правильно/неправильно, а в "сохраняем совместимость с StrLogicalCompare/нет". Если нет, то текущий вариант понятное дело лучше, я за него
Здравствуйте, Sinix, Вы писали:
AVK>>И? Разве правильно так реагировать на пробелы? S>Тут имхо вопрос не в правильно/неправильно, а в "сохраняем совместимость с StrLogicalCompare/нет".
А это уже зависит от юзкейсов. Поскольку предложил не я, то ХЗ.
По моему опыту 99% применений сортировки это чтобы глазом глядеть какие то списки, для чего точная совместимость вобщем то побоку. Оставшийся 1% это бинарный поиск, но там вообще пофик какая сортировка, лишь бы была стабильной.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinix, Вы писали:
AVK>>Большая часть настраивается. И ну ее нафик, такую каноничность как в примере — читать неудобно. S>Ну тут опять-таки вкус фломастеров
Да причем тут вкус? Это в игрушечном примере вроде все видать. А когда строки длинные, что часто бывает, то перемещать глаз в конец строки только чтобы понять что это за конструкция это уже перебор. А оно еще и вложенным может быть.
Если что я по опыту говорю. IT любит в таком виде писать — при чтении кода глаз сломаешь, дико неудобно.
S>Из практики, когда не у всех в команде есть решарпер, поддержать общий стиль форматирования заметно сложнее — получается "или все прогинаемся под R#, или никак".
При чем тут "прогинаемся под R#"? Есть вполне конкретный стиль кодирования, решарпер вполне его реализует. Хочется StyleCop — я не против. Но сам я им не пользуюсь, поэтому и возиться с настройками его не буду.
Да, конкретно StyleCop еще и весьма интрузивный — если его не поставить, проекты с его использованием не открываются, потому что он свой таргет в csproj втыкивает. Вкупе с кучей его безумных правил и вашим предложением treat warnings as errors будет весело. В комплекте с обязательностью тестов и комментов на английском как бы это не стало великим тормозом — даже мелкий метод потребует массу работы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали: AVK>Можно, если поподробнее опишешь.
Ну сценарий простой:
public static class InvariantString
{
public static CultureInfo Culture => CultureInfo.InvariantCulture;
public static string ToInvariantString<T>(this T s) where T : IFormattable => s.ToString(null, Culture);
public static string ToInvariantString<T>(this T s, string format) where T : IFormattable => s.ToString(format, Culture);
// ...public static double ParseDouble(string s) => double.Parse(s, Culture);
}
public class Program
{
static void Main(string[] args)
{
Right();
Wrong();
}
private static void Wrong()
{
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
var x = 12.3.ToString();
// ...
Thread.CurrentThread.CurrentCulture = new CultureInfo("ru-RU");
double y = double.Parse(x); // FAIL
Console.WriteLine(y);
}
private static void Right()
{
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
var x = 12.3.ToInvariantString();
// ...
Thread.CurrentThread.CurrentCulture = new CultureInfo("ru-RU");
double y = InvariantString.ParseDouble(x); // OK
Console.WriteLine(y);
}
}
В реальности разумеется CurrentCulture может поменять что угодно — от перекидывания в другой поток и до чтения на другой машине.
В InvariantString дублируем основные методы из String, вызываем c InvariantCulture. Смысл в том, чтоб не путаться с текущей культурой.
Кто с ходу назовёт хотя бы пару методов, в которых используется culture-insensitive?
Здравствуйте, AndrewVK, Вы писали:
AVK>ToInvariantString добавил, перебитые методы string тогда сам добавь. И за тобой еще как минимум ассерты.
В курсе Со следующей недели постараюсь.
Здравствуйте, Sinix, Вы писали:
S>Чот я не уверен в best ever.
Исключительно как потенциальный пользователь библиотеки, выскажусь в пользу варианта Args. У нас в проекте как раз хелпер с именно таким названием, проблем не припомню.
S> //NOTTODO: IT: The name is the best ever. Don't change it.
S> public static string Args([NotNull] this string format, params object[] args) => string.Format(format, args);
S>Чот я не уверен в best ever.
S>UPD: Я знатно протупил с вариантом .Format(), AndrewVK намекнул ниже Но Args мне всё равно не нравится
+1. Я делаю FormatWith:
text.FormatWith("a", 2); // Invariant by default
text.FormatWith(CultureInfo.CurrentCulture, "a", 2);
"Invariant by default" академически кажется спорным, ибо и WTF и неожиданно, зато покрывает мои без малого 100% случаев :о)
Можнос делать InvariantFormatWith.
Было бы не плохо давать ссылки редактированием стартового сообщения. И продублировать в "Проектах".
А вообще я бы в стартовом сообщении указал ссылку на репо а, ссылку на нугет писал в readme.md. А тут написать новым сообщением, что в ридми добавлена/изменена такая-то ссылка.
Здравствуйте, AndrewVK, Вы писали:
S>>[/code]Если нет реальных сценариев использования, то лучше выбросить. AVK>Подождем что автор предложения ответит.
(там в самом начале) о методах, возвращающих интерфейсы, аналогах Enumerable.Asenumerable.
Лично мне такие методы под конкретные типы не были нужны ни разу, а интерфейсные вот напротив.
Здравствуйте, fatkh, Вы писали:
F>Исключительно как потенциальный пользователь библиотеки, выскажусь в пользу варианта Args. У нас в проекте как раз хелпер с именно таким названием, проблем не припомню.
Здравствуйте, _Raz_, Вы писали:
AVK>>Фид с серверными сборками пакетов — https://ci.appveyor.com/nuget/codejam _R_>Было бы не плохо давать ссылки редактированием стартового сообщения. И продублировать в "Проектах".
В проектах все есть. Здесь я просто продублировал на всякий случай.
_R_>А вообще я бы в стартовом сообщении указал ссылку на репо а, ссылку на нугет писал в readme.md. А тут написать новым сообщением, что в ридми добавлена/изменена такая-то ссылка.
Здравствуйте, Sinix, Вы писали:
S>Чот я не уверен в best ever.
Поверь мне пока на слово К этому имени очень быстро привыкаешь настолько, что все остальные потуги придумать что-либо более удобоваримое выглядят жалкими и смешными.
Хотя я не настаиваю. Давай оставим Format. Остальные предложенные имена подпадают под твои же аргументы.
S>Аргументы против в произвольном порядке:
S>0. Guidelines. Имя метода не совпадает с производимым действием.
Всё так. Но бывают и исключения, которые только подтверждают правила.
С другой стороны к данному методу следует относится не как к действию, а как к параметрам форматной строки. Иначе, если следовать всем буквам guidelines, то форматную строку нужно запретить и заменить её на конкатенацию.
S>1. WTF test fail. S>Возьми произвольного девелопера и спроси: "эй, у нас будет метод-расширение для форматирования строк, как он должен выглядеть?"
Если честно, то я почти никогда не объявляю форматную строку отдельно от string.Format. Поэтому выглядеть это будет так:
return"Hello, {0}".Args(wellKnownNames[0]);
Учитывая подсветку и поддержку решарпера вся конструкция воспринимается не как строка и действие, а как единое целое.
S>2. Совместимость с другими решениями. В куче проектов используется SmartFormat с extensions вида
Это опять лишь твои предпочтения. Если это переназвать в Format, то станет сразу менее WTF? Давай переназовём.
S>3. Too noisy. Подобные узкоприменимые расширения должны быть opt-in.
Это проблема не только этого метода, а любого расширения. Я сам хотел поднять эту тему. Сейчас у нас все расширения находяться в основном пространстве имён, что автоматически добавляет их все. При этом вопрос узкоприменимости представляет собой в чистом виде вкусовщину, поэтому конфликт интересов неизбежен. Дробить всё как ты предлагаешь по пространсту имён на каждый метод, тоже не дело. Но что-то решать надо. Как минимум я бы перенёс все расширения куда-нибудь в CodeJam.Extensions. И заодно перетасовал бы файлы в проекте. Соответсвие папок пространсвам имён тоже вроде пока никто не отменял.
S>Это всё не ради срача, а чтоб сделать код лучше. Если решение принципиально будет "всё равно останется как есть" — можно не спорить, просто так и скажи
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
