Василий Банников

На сколько я знаю, корутины в Unity реализованы через IEnumerator и объекты WaitForSeconds.

IEnumerator и IEnumerable - это стандартные интерфейсы, которые используются для реализации перечислений/коллекций и итераторов.

А вот ожидание в C# ты можешь получить через метод Thread.Sleep (в синхронных методах) или await Task.Delay (в асинхронных методах).

В общем, условно, такой код, глядя на который, даже самые суровые критики не могли бы найти к чему придраться.

Всегда можно к чему-то придраться.
Качество архитектуры можно понять только в динамике - легко ли вносить изменения в продукт, или сложно.
А так есть eShopOnWeb и eShopOnContainers

В интернете для бизнеса больше гарантий, чем для частников. Гарантируется доступность канала, и SLA, и скорость реакции для неполадки.

Ну и ещё тут приходит в гости маржинальность. Бизнес является гораздо более платёжеспособным клиентом, чем частник. По тому можно легко завысить ценник в 10 раз.

Создать новый массив такого размера, чтобы туда уместился новый элемент, скопировать в него элементы из старого массива, удалить старый массив, записать в пустое место нужный элемент.

С удалением всё аналогично.

std::vector делает всё примерно то же самое, только он не создаёт новый массив при удалении (если не вызвать truncate), а просто уменьшает счётчик занятых элементов, да и при добавлении новых элементов создаёт массив с запасом.

Могу ли я, используя необходимые данные от провайдера (которые он предоставляет для подключения интернета например) подключиться к кз интернету находясь в рф? и тем самым не платить за европейский серв.

Нет, не можешь. Сначала твой компьютер в любом случае попадает в физическую сеть провайдера, а потом уже в мировой интернет.

Если тебе нужен казахский интернет, то тебе всё равно нужно использовать VPN, где сервер будет в казахстане (хотябы у твоего друга)

В твоём случае логичнее было бы использовать метод any, если ты хочешь просто проверить, что такие элементы существуют.

Как вариант ты можешь сделать так, если тебе нужны потом переменные poz_*:

fn read() -> Result<(), io::Err> {
  //let vec: Vec<u8> = !vec[2, 5, 8, 10, 15, 16];
  let pos1 = self.responce.iter().position(|&el| el == 8).ok_or_else(||io::Err::new("understading message"))?;
  let pos2 = self.responce.iter().position(|&el| el == 15).ok_or_else(||io::Err::new("understading message"))?;
  let pos3 = self.responce.iter().position(|&el| el == 12).ok_or_else(||io::Err::new("understading message"))?;
  return Ok(());
}

Ещё можно попробовать let-else

Ну ты можешь сделать так:

switch(parameter) {
  case IPrintService_IncomeProductLabelParams incomeProductLabel: {
    // ...
    break;
  }
  case IPrintService_WLabelParams wLabel: {
    // ...
    break;
  }
  // итд
  default:
    // ...
  break;
}

Но мне не понятен смысл женерика и интерфейсов с пропертями.
Ты собираешься делать параметры ещё и структурами?
В принципе тут можно избавиться от интерфейсов вообще и оставить только конкретные классы, а в IPrintService сделать несколько перегрузок, например.
Или сделать по интерфейсу для каждого типа этикеток.

Вообще, я у тебя тут вижу три разные вещи у этикеток:
1. Какой принтер используется (PrinterName)
2. Параметры задания на печать (Copy)
3. Параметры самой этикетки. Её тип и, например, SKU товара.
Попробуй подумать с этой стороны.
Например ты можешь сделать такой IPrinter, который будет принимать в себя PrintTask, у которого будет написано количество нужных копий и Payload который будет уже самой этикеткой.
Конкретная реализация IPrinter может быть привязана к одному физическому принтеру.

А Payload ты можешь формировать отдельно от сервиса печати. Например у тебя может быть какая-нибудь "служба шаблонов этикеток", в которую ты передаёшь объект с параметрами этикетки, а она отдаёт тебе уже сформированный объект этикетки, который пригоден для печати (Что там вообще принтер принимает? Картинку?)

Попробуй вместо того что у тебя написано использовать entry()

self.on_event_closure
  .entry(event)
  .or_insert_with(Vec::new)
  .and_modify(move |vec| vec.push(f));

А нельзя borrow as mutable из-за того что get заимствует on_event_closure

Никогда если честно не видел, чтобы умножали на 0.5 там, где нужно поделить на 2.

В теории, если у тебя очень глупый компилятор, то умножение на 0.5 будет быстрее, чем деление на 2.

Ещё это может иметь смысл, если у тебя есть число типа int, и ты хочешь его поделить на два, и чтобы в результате получилось число типа double. Тогда умножение на 0.5 будет компактнее, чем приведение типов явно.

В общем нужно смотреть на конкретную ситуацию. А математического смысла за этим не стоит

У меня было что-то похожее.
Так что предположу, что это норма.

Но по-хорошему ты не должен оставаться 1-на-1 с кодом и должен быть где-то человек, которому ты можешь задавать вопросы (пусть он и не будет с тобой рядом весь день сидеть)

Ну думал что буду писать код и что-то полегче.А тут только читать код, разбираться недели -две

Тогда это норма вдвойне.
В 90% случаев ты попадаешь не в стартап, где нет кода, а уже в сложившуюся команду, особенно если ты новичок.

Ну тут либо json (было бы хорошо, если СУБД поддерживает их нативно и можно построить индекс по содержимому json)

Либо паттерн Entity-Attribute-Value (загугли)