Илиян качи първо решение на 03.11.2019 22:23 (преди почти 6 години)
Имаш интересен подход към задачата. Харесва ми enum-а Radix
, макар че за толкова проста задача изглежда като че количеството конвертиране не си заслужава употребата му. Добро упражнение е, ако не друго.
Разделянето на кода на определени парчета е деликатна работа. На няколко места използваш unwrap
, понеже валидацията и употребата ти са разделени. Това има проблема, че в рамките на една функция, където се използва unwrap
, ти имплицитно разчиташ на това, че преди това някак си валидирал, че този unwrap
няма да гръмне. А това може често да е опасно предположение. В една по-голяма система, валидацията и обработката може да са ти много по-ясно отделени и "валидация" да значи и някаква форма на preprocessing. В случая, функциите които валидират и тези, които обработват, са смешени -- на едно и също ниво са и не е очевидно, че едните трябва да се викат преди другите. Basically, is_valid_digits
и sum_digits
са tightly coupled -- има връзка между тяхната употреба, но няма връзка между тях в кода.
Ако нямаше is_valid_digits
, а вместо това sum_digits
връщаше опционална стойност, и по-нагоре digital_root_as_string
също връщаше Option<String>
, мисля, че кода щеше да се опрости доста. Пробвай, ако искаш.
Давам ти и бонус точка за тестовете, дори и да не съм съвсем съгласен как си ги структурирал :).
Благодаря много за изчерпателните коментари. Определено ще я пренапиша. Ако кача друго решение, ще го погледнеш ли?
Качването на друго решение няма как да стане, понеже сайта автоматично блокира качване на решения след крайния срок. Приеми го като feedback, за който сам да си помислиш, и пробвай да го приложиш на второ домашно :).
Тук вероятно можеше да използваш
char::from_digit
Търсих тази функция на грешното място - за u32.
Мда, често е трудно да намериш правилното място за такива неща :). С опита ще стане по-лесно.
Този тип тестове са малко трудни за четене. Щеше да е само 3 реда да се напише без цикъла:
На теория, твоя метод ще е по-кратък ако имаш повече примери, но не е дължината главния проблем. Правенето на списъци с входове, изходи, и резултати има ефекта, че "обръща" логиката. Трябва да напасваш по колони какво се очаква да е равно на какво друго, и ако тези списъци са дълги, това може да е доста досадно. Може да е полезно за някои ситуации, но много често няма да е.
Тестовете често е по-удачно да имат повторение, отколкото твърде много абстракция, понеже стават трудни за четене и трудни за дебъгване. Примерно, ако този тест fail-не, реда който ти бъде даден, ще бъде просто ред в цикъла и ще трябва да гледаш конкретните стойности, за да разбереш кой пример се е провалил. Ако тези стойности са по-сложни, това може да иска доста взиране в екрана.
Благодаря за коментара, отдавна се чудя кой е по - добрия подход в такива ситуации. Може ли да се каже, че тези цикли, ако се правят, просто трябва да се направи property-based testing?
Property-based testing може би би ти свършило работа, стига да намериш какви property-та искаш да тестваш. Обикновено property-based testing е добро допълнение към тестове, които валидират познати вход и изход.