код стайл

[KateBushueva]

Здесь несколько моментов

1. В коде в некоторых местах происходит смешение кэмэл-кейса и нижнего подчеркивания - лучше придерживаться одного стиля: для внутренних сущностей - кэмэлКейс, для джейсонов - подчеркивания.
2. именования сущностей: нет необходимости дублировать имя даты внутри самой даты: если дата называется Attachment , не нужно поля этой даты начинать с attach_ , достаточно просто type , ну или если слово зарезервировано, то что-то иное придумать
3. комментарии: лучше избегать дублирующих код комментариев - то, для чего нужна сущность, должно быть понятно из ее имени, а не из комментария. Тем более странно, когда комментарий почти полностью дублирует имя сущности

[KateBushueva]

Кстати, в конктретном случае с Attachment лучше использовать тип сумму, а не произведение: аттачмент может быть только одним из вышеперечисленных типов (а не может содержать сразу несколько ), это логически определение типа суммы (а не произведения)

[KateBushueva]

Кстати, в конктретном случае с Attachment лучше использовать тип сумму, а не произведение: аттачмент может быть только одним из вышеперечисленных типов (а не может содержать сразу несколько ), это логически определение типа суммы (а не произведения)

я пожалуй вынесу это в отдельный ишью, чтобы не засорять здесь

[LyuPo7]

Поменяла везде. Теперь не перемешиваются стили: camalCase только для внутренних Типов; нижнее подчеркивание только для json.

1. В коде в некоторых местах происходит смешение кэмэл-кейса и нижнего подчеркивания - лучше придерживаться одного стиля: для внутренних сущностей - кэмэлКейс, для джейсонов - подчеркивания.

[LyuPo7]

Сделала отдельные модули для всех сущностей, чтобы не пересекалось именование полей и где нужно использую qualified import. -> Это позволило название полей сделать краткими (без attach_ и тд). Оставила только такие поля как 'update_type' (где используются в api резервированые слова), но в этих случаях пишу инстансы руками, так что для остальных полей этих же типов поля без префиксов.

2. именования сущностей: нет необходимости дублировать имя даты внутри самой даты: если дата называется `Attachment` , не нужно поля этой даты начинать с `attach_` , достаточно просто `type` , ну или если слово зарезервировано, то что-то иное придумать

[LyuPo7]

Убрала излишние комментарии (оставила только информативные на мой взгляд)

3. комментарии: лучше избегать дублирующих код комментариев - то, для чего нужна сущность, должно быть понятно  из ее имени, а не из комментария. Тем более странно, когда комментарий почти полностью дублирует имя сущности

[KateBushueva]

по первым пунктам соглашусь, по поводу комментариев - еще остались в некоторых модулях (например, в логах). Здесь возникает также вопрос по именованию сущностей

Например, в данном случае можно первую фунцию назвать convertValue , а вторую readKey - в таком случае уходит необходимость оставлять комментарии. В именах сущностей чаще всего не нужно указывать тип (обычно тип мы видим из сигнатуры). То есть мысль в том, что если есть необходимость оставить комментарий, что делает та или иная сущность, то надо задуматься, корректно ли эта сущность именована. Имеет смысл оставлять комментарии, отвечающие на вопрос "почему", а не "что", если есть такая необходимость.

[LyuPo7]

Свела комменты к минимуму.

по первым пунктам соглашусь, по поводу комментариев - еще остались в некоторых модулях (например, в логах).

Поменяла названия.

Например, в данном случае можно первую фунцию назвать convertValue , а вторую readKey - в таком случае уходит необходимость оставлять комментарии. В именах сущностей чаще всего не нужно указывать тип (обычно тип мы видим из сигнатуры). То есть мысль в том, что если есть необходимость оставить комментарий, что делает та или иная сущность, то надо задуматься, корректно ли эта сущность именована. Имеет смысл оставлять комментарии, отвечающие на вопрос "почему", а не "что", если есть такая необходимость.