Конечно assertTrue может потребовать сообщения: assertTrue("The fruit was not sweet as it MUST be.", fruit.isSweat())
Но можно написать так: assertEquals(true, fruit.isSweat()), и сообщение станет "expected:<true> but was:<false>" — на практике такого сообщения обычно достаточно.
Статья, для тех, кто уже слышал о LFS, но еще не нашел в себе сил, чтобы погрузиться и ознакомиться.
Т. е. для таких, каким был я, пару недель тому назад.
Рекомендую в книжке «Идеальный код», Глава 18. «Реализация словарей Python: стремление быть всем во всем полезным».
Со словарями в Python не все просто. Они имеют различные реализации, могут переиспользоваться и могут налету переключать функцию сравнения ключей.
Я в детстве пытался на реле собрать 4x битный компьютер. У меня был ящик каких-то реле, 12V аккумулятор и куча проводов. И вот соединив пару десятков реле я подключаю всю эту кашу проводов к аккумулятору… Как они, блин, застрекочат все разом!
Чуть не обгадился.
Недружественное поведение по отношению к пользователю заключалось в том, что по наступлению какого-то момента времени, ПРИ ОТСУТСТВУЮЩЕМ доступе к инету, 2гис перестал работать.
Ни карт, ни расписаний, ни телефонов.
ПЕРЕСТАЛ! И выставил невыполнимые (на тот момент) требования!
Я бы еще явно определил порядок применения правил. В вашем коде порядок «по максимуму очков добавленных от применения очередного правила к оставшимся костям», и я бы упростил его до «первыми применяются правила приносящие большее кол-во очков» и задал его так:
Но часто встречается другой порядок: «В любом порядке, главное получить наибольшее количество очков»:
Правила:
111xx — 300
11xxx — 200
221xx — 200
Вход:
11122. Ваша реализация посчитает 300 очков, но возможен вариант с 400 очками.
List<Rule> rules = ...
for(List<Rule> orderedRules : perestanovka(rules)) {
// Посчитать для каждого варианта применения правил и выбрать вариант с самым большим score.
}
А может оказаться, что игроку разрешается выбирать из возможных вариантов. Тогда придется интерфейс этой части системы менять.
Повторюсь, я бы еще явно задал порядок применения правил.
Нет, не корректно.
1) В сигнатуре метода появится throws Throwable
2) В catch ничего нельзя делать, т.к. в случае Error JRE ничего не гарантирует
Closer.rethrow ничуть не более корректен. Во-первых он пытается создать объект (new RuntimeException(...)), т.е. в случае нехватки памяти код попытается создать новый объект и может получить нехватку памяти, но уже в другом месте. Во-вторых со стеком то же самое.
Не зря он помечен Beta.
Как меня утомили такие кэтчи.
Никогда не ловите Throwable или Error. В случае их возникновения система должна падать в дамп, после чего программист должен узнать причины возникновения этих Error или Throwable и разобраться с ними.
Конечно можно после падения автоматически поднять новенький процесс. Однако делать это нужно только из другого процесса, или из cron-а.
А то получается, что поймав Error или Throwable, система не может самостоятельно решить проблему, переходит в нештатное состояние и счастливо тупит мешая работе всех окружающих систем.
Я даже однажды видел попытку сделать memory dump в случае out of memory вручную путем запуска внешнего процесса из jsp.
Как бы проверить оба варианта (а лучше все три, тот что с DSL тоже) на десятке живых программистов?
И оценить такие параметры:
— Время затраченное на понимание упавшего теста
— время на исправление теста, например чтобы проверялось второе место
— количество заблуждений после знакомства с тестом
Вот фрагмент hexdump-а того, что выдал ipconfig -all > tmp.txt
0140 74 20 61 64 61 70 74 65 72 20 91 a5 e2 a5 a2 ae t adapte r Сетево
0150 a5 20 af ae a4 aa ab ee e7 a5 ad a8 a5 20 42 6c е подклю чение Bl
0160 75 65 74 6f 6f 74 68 3a 0d 0a 0d 0a 20 20 20 4d uetooth: .... M
Первый символ в третей строке русская е и у нее код А5. Это кодировка cp866. ipconfig -all > tmp.txt вызывался из штатной консоли cmd.exe сразу после вызова chcp 65001
У меня MinGW (тот что с Git-ом идет) и mintty.exe (более-менее правильный терминал, можно даже мышкой менять размер окна), а еще в стартовом скрипте я вызываю chcp.com 65001 (и в настройках терминала стоит utf-8). Короче почти все что нужно работает как надо.
И вот я решил проверить как работает ipconfig /all | grep IP
Проблему со слешем можно обойти минусом (ipconfig -all | grep IP) а кодировка должна была отработать правильно.
Но однако оказалось, что ipconfig даже в родной консоли работает только в кодировке 866, а в 65001 не работает.
Бу-Га-Га, 20-летняя ось, а тупит как курсовик второкурсника!
До последнего момента я считал, что главный источник сложности использования компьютера — скрытые состояния. Но готов признать, что изменчивость интерфейса тоже вносит заметный вклад.
assertEquals(Shape.ROUND, fruit.getShape())— вот эта строчка сформирует суперское сообщение об ошибке и кристально ясный стэк трейс.assertThat(someFruit, is(round()))— выдаст запутанный стэк трейс.Конечно assertTrue может потребовать сообщения:
assertTrue("The fruit was not sweet as it MUST be.", fruit.isSweat())Но можно написать так:
assertEquals(true, fruit.isSweat()), и сообщение станет"expected:<true> but was:<false>"— на практике такого сообщения обычно достаточно.Я в недоумении.
Т. е. для таких, каким был я, пару недель тому назад.
Со словарями в Python не все просто. Они имеют различные реализации, могут переиспользоваться и могут налету переключать функцию сравнения ключей.
Чуть не обгадился.
Ни карт, ни расписаний, ни телефонов.
ПЕРЕСТАЛ! И выставил невыполнимые (на тот момент) требования!
И нет доступа к старой (вчерашней) базе. Вот спасибо, подлецы!
Но часто встречается другой порядок: «В любом порядке, главное получить наибольшее количество очков»:
Правила:
111xx — 300
11xxx — 200
221xx — 200
Вход:
11122. Ваша реализация посчитает 300 очков, но возможен вариант с 400 очками.
А может оказаться, что игроку разрешается выбирать из возможных вариантов. Тогда придется интерфейс этой части системы менять.
Повторюсь, я бы еще явно задал порядок применения правил.
2) Что можно? Создавать объекты нельзя, вызывать методы нельзя. И?
1) В сигнатуре метода появится throws Throwable
2) В catch ничего нельзя делать, т.к. в случае Error JRE ничего не гарантирует
Closer.rethrow ничуть не более корректен. Во-первых он пытается создать объект (new RuntimeException(...)), т.е. в случае нехватки памяти код попытается создать новый объект и может получить нехватку памяти, но уже в другом месте. Во-вторых со стеком то же самое.
Не зря он помечен Beta.
Как меня утомили такие кэтчи.
Никогда не ловите Throwable или Error. В случае их возникновения система должна падать в дамп, после чего программист должен узнать причины возникновения этих Error или Throwable и разобраться с ними.
Конечно можно после падения автоматически поднять новенький процесс. Однако делать это нужно только из другого процесса, или из cron-а.
А то получается, что поймав Error или Throwable, система не может самостоятельно решить проблему, переходит в нештатное состояние и счастливо тупит мешая работе всех окружающих систем.
Я даже однажды видел попытку сделать memory dump в случае out of memory вручную путем запуска внешнего процесса из jsp.
Я имел ввиду, что исправление теста, которые должен сделать разработчик, обусловлено изменением требований.
И оценить такие параметры:
— Время затраченное на понимание упавшего теста
— время на исправление теста, например чтобы проверялось второе место
— количество заблуждений после знакомства с тестом
В Лондоне?! И их никто не засудил?! Мало верится.
ipconfig -all > tmp.txtПервый символ в третей строке русская е и у нее код А5. Это кодировка cp866.
ipconfig -all > tmp.txtвызывался из штатной консоли cmd.exe сразу после вызова chcp 65001И вот я решил проверить как работает ipconfig /all | grep IP
Проблему со слешем можно обойти минусом (ipconfig -all | grep IP) а кодировка должна была отработать правильно.
Но однако оказалось, что ipconfig даже в родной консоли работает только в кодировке 866, а в 65001 не работает.
Бу-Га-Га, 20-летняя ось, а тупит как курсовик второкурсника!