Основной канал. Простые вопросы сюда: https://gitter.im/ruRust/easy . Поддержите сообщество: https://www.patreon.com/mkpankov . Правила: https://rustycrate.ru/rules.html . Помощь в исправлении ошибок, отладке, технические вопросы. Оффтопик - https://gitter.im/ruRust/offtopic . Сайт - http://rustycrate.ru/ . Форум - http://forum.rustycrate.ru/
rustup update
pub fn get_best_block_id(&self) -> Result<Id<GenBlock>, PropertyQueryError> {
self.db_tx
.get_best_block_id()
.map_err(PropertyQueryError::from)
.map(|bid| bid.expect("Best block ID not initialized"))
}
get_gen_block_index
возвращает обобщенный тип, а get_block_index
только для блоков в цепочке. Соответственно, где генезиса быть не должно пытаемся использовать get_block_index
, а где он может быть то обобщенную версию
for (_input_idx, input) in inputs.iter().enumerate()
- вот и зачем делать enumerate только ради того, чтобы проигнорировать индекс?outpoint.output_index() as usize
- а это каст с потерей информации или без? Не зная оригинальный тип, не скажешь. Многие за это не любят as-касты.
match
с одним "рабочим" вариантом обычно принято писать как if let
, если задача не в том, чтобы гарантированно отрабатывать новые варианты в случае их добавления. Отдельный вопрос, зачем в хвостовой позиции continue
вместо {}
for (_input_idx, input) in inputs.iter().enumerate()
- вот и зачем делать enumerate только ради того, чтобы проигнорировать индекс?outpoint.output_index() as usize
- а это каст с потерей информации или без? Не зная оригинальный тип, не скажешь. Многие за это не любят as-касты.
Согласен косяк
match
с одним "рабочим" вариантом обычно принято писать какif let
, если задача не в том, чтобы гарантированно отрабатывать новые варианты в случае их добавления. Отдельный вопрос, зачем в хвостовой позицииcontinue
вместо{}
За if let ругаются у нас, типа не очевидно как раз будут ли новые элементы и не очевидно обработаны ли все элементы.
По поводу, continue
тоже косяк
let index: usize = outpoint.output_index().try_into().expect("16-bit systems not supported");
(а скорее сделал бы, чтобы метод output_index
делал это внутри себя и возвращал уже usize)...
break Ok(block_index_walk)
, и аналогичные - это на самом деле не брик а ретурн. Такой стиль сбивает с толку. Я бы писал break только если там что-то типа let v = loop{ .... break result....}
. А если это возврат - то это ретурн! Форматирование - ну на любителя. Во-первых, я бы разделял функции пустой строчкой. Между строкой 59 и 60 (и по всему коду аналогично) я бы вставил пустую. Кроме этого, я предпочитаю, чтобы аргументы функций были в строчку, а не в столбик. Но когда их много и функцию не разобьешь - то приходится и в столбик. Но я стараюсь не делать так. Но честно говоря, о стиле просто договариваются заранее, так что это ж не предмет, к которому пристебываться надо. Между сторокой с импл и функцией я бы тоже вставил пустую строчку(например - между 93 и 94). Всякие log::trace!
я б заменил на trace!
. Но это все неособо принципиальные замечания. Может, у них были претензии именно к архитектуре? Что еще? Например, в 156 строке использование Arc предполагает, что это все многопоточный код. Если код однопоточный, то там Rc уместней (но все зависит от общей архитектуры, о которой я не знаю ничего). И кстати, говоря. В строках 754-760 дергается запись в базу данных. Там идет add_to_block_index, set_block_index, add_block. Я ничего не знаю о базе и может я не прав - но если это все выполняется в несколько потоков (на что намекает упомянутый выше Arc), то эти 3 операции будут не атомарны? И если это действительно так - то вот это и было реальной причиной недовльства! А еще db_tx имеет тип BlockchainStorageRead - хотя там запись в строках 754-760. Может его надо просто обозвать BlockchainStorage
, если там и запись тоже.