fix after review

Author: Kuzmin

university/memos/best-practices.md

@@ -65,7 +65,7 @@ sidebar_position: 0
     <ul>
         <li>Преобразуйте сетевые сущности в свои — доменные и используйте их во всем приложении</li>
         <li>Если в приложении вы работаете с сетевыми сущностями, то в случае, если на сервере что-то изменят, например изменят имя какого-то поля или поменяют вложенность полей, то вам придется исправлять все места, где используется эта сущность. <p>А если при получении сетевой сущности вы сразу преобразуете(маппите) ее в доменную, то при изменении сетевой вам нужно будет просто изменить функцию-маппер.</p></li>
-        <li>Если от сервера где-то приходит <code>null</code> вы можете как-то заменить на <code>not-null</code> значение, чтобы удобнее работать в приложении. Например, если приходит поле <code>description = null</code> — в маппере можно заменить на пустую строку</li>
+        <li>Если от сервера где-то приходит <code>null</code>, вы можете как-то заменить его на <code>not-null</code> значение, чтобы удобнее работать в приложении. Например, если приходит поле <code>description = null</code> — в маппере можно заменить его на пустую строку</li>
         <li>Доменная сущность пишется независимо от серверной, она включает только то, что реально будет использоваться приложением, а не хранит абсолютно все данные, полученные от сервера</li>
     </ul>
 </details>
@@ -141,7 +141,7 @@ sidebar_position: 0
 <details>
   <summary>Никогда не обрабатывайте <code>Error</code>-ы в <code>catch</code></summary>
     <ul>
-        <li>У <code>Throwable</code> два наследника — <code>Exception</code> и <code>Error</code>. <code>Exception</code> нужно обрабатывать, они исправимы, а <code>Error</code>-ы — неисправимы, их обрабатывать не надо. Приложение должно упасть с информацией о том, что пошло не так (в <code>Error</code> эта информация)</li>
+        <li>У <code>Throwable</code> два наследника — <code>Exception</code> и <code>Error</code>. <code>Exception</code> нужно обрабатывать, они исправимы, а <code>Error</code>-ы — неисправимы, их обрабатывать не надо. Приложение должно упасть с информацией о том, что пошло не так (в <code>Error</code> эта информация есть)</li>
         <li> изучите <a href="https://rollbar.com/blog/java-exceptions-hierarchy-explained/">документацию</a></li>
     </ul>
 </details>
@@ -154,13 +154,14 @@ sidebar_position: 0
   <summary> Устанавливайте версии подов в <code>Podfile</code></summary>
     <ul>
         <li> Версии установленных подов можно посмотреть после установки подов в файле <code>Podfile.lock</code></li>
-        <li> Если версии подов не будут явно обозначены - то у нового разработчика, или у тебя (на другом компе) при установке подов могут подтянуться более новые версии. Есть вероятность, что в этих новых подах что-то будет изменено и проект не скомпилируется. Либо, как сейчас популярно, в библиотеку всунут зловредный код в новой версии, он тоже скачается :) </li>
+        <li> Если версии подов не будут явно обозначены - то у нового разработчика или у тебя (на другом компе) при установке подов могут подтянуться более новые версии. Есть вероятность, что в этих новых подах что-то будет изменено и проект не скомпилируется. Либо, как сейчас популярно, в библиотеку всунут зловредный код в новой версии, и он тоже скачается :) </li>
     </ul>
 </details>
 1. 
 <details>
-  <summary> Называйте <code>ViewController</code>-ы правильно</summary>
-        Все <code>ViewController</code>-ы должны называться с окончанием <code>ViewController</code>, а не <code>Screen</code>, потому что <code>Screen</code> — это экран девайса. <code>ViewController</code> не обязательно занимает весь экран, их на экране сразу несколько: твой собственный, <code>UINavigationController</code>, <code>UITabBarController</code>, модалки
+  <summary> Называйте экраны приложения правильно</summary>
+    В UIKit-экранах используйте суффикс <code>ViewController</code> — это системная сущность, которая не обязательно занимает весь экран (их может быть несколько: ваш контроллер, <code>UINavigationController</code>, <code>UITabBarController</code>, модалки).  
+    В SwiftUI и на Android (Compose) для экранов приложения используйте суффикс <code>Screen</code> — это абстракция экрана приложения, а не экран девайса.
 </details>
 1.
 <details>
@@ -207,7 +208,7 @@ SplashScreen делать в `LaunchScreen.storyboard`, а не в `SplashViewCo
   <summary>Работа с ресурсами из <code>R.swift</code></summary>
     <ul>
         <li>Когда вы добавили картинки, цвета и другие ресурсы в Assets, вы можете получить к ним доступ через <code>R.swift</code>, например: <code>R.image.somethingImage()</code></li>
-        <li>Некоторые ресурсы, такие как цвета, <code>R.swift</code> возвращает <code>nullable</code>. В этом случае <code>guard</code> обработку делать не нужно, потому что раз <code>R.swift</code> предоставил доступ к переменной, значит смог ее сгенерировать на основе цвета. <p>Поэтому, чтобы узнать о том, что при наличии переменной ресурса самого ресурса нет — можно использовать форскаст. Таким образом, если все таки произойдет ошибка — мы будем разбираться в причине, а если бы мы обработали <code>null</code> — то не узнали бы, что такая ошибка может произойти</p></li>
+        <li>Некоторые ресурсы, такие как цвета, <code>R.swift</code> возвращает <code>nullable</code>. В этом случае <code>guard</code> обработку делать не нужно, потому что раз <code>R.swift</code> предоставил доступ к переменной, значит смог ее сгенерировать на основе цвета. <p>Поэтому, чтобы узнать о том, что при наличии переменной ресурса самого ресурса нет — можно использовать форскаст. Таким образом, если все-таки произойдет ошибка — мы будем разбираться в причине, а если бы мы обработали <code>null</code> — то не узнали бы, что такая ошибка может произойти</p></li>
     </ul>
 </details>
 
@@ -248,7 +249,7 @@ SplashScreen делать в `LaunchScreen.storyboard`, а не в `SplashViewCo
 ## Android
 ### Logic
 1.
-Compose не используйте `lifecycleScope` для задач, связанных с UI. Для корутин, живущих только пока composable в композиции, используйте `LaunchedEffect` или `rememberCoroutineScope()`.
+В рамках Composable функций не используйте `lifecycleScope` для задач, связанных с UI. Для корутин, живущих только во время композиции, используйте `LaunchedEffect` или `rememberCoroutineScope()`.
 1.
 Обрабатывайте стейты на Android [правильно](../../learning/state#обработка-на-android)
 1.
@@ -300,12 +301,12 @@ request.removeObserver(requestObserver)
         <li>Хороший нейминг: <code>DetailInfoScreen</code> и <code>DetailInfoContent</code></li>
     </ul>
 </details>
-1. Отступы всегда должны быть кратны ***4*** (4, 8, 16, 24, 32), если в дизайне по-другому, задавайте вопросы
+1. Отступы всегда должны быть кратны 4 (4, 8, 16, 24, 32). Если в дизайне по-другому, задавайте вопросы
 1. Если какой-то набор элементов используется на нескольких экранах — выносите его в отдельную `Composable` функцию и переиспользуйте
-1. Не передавай ViewModel глубоко в дерево функций, UI должен зависеть от данных, а не от ViewModel.
+1. Не передавайте ViewModel глубоко в дерево функций. UI должен зависеть от данных, а не от ViewModel.
 1. 
 <details>
-  <summary>State hoisting — выноси состояние наверх</summary>
+  <summary>State hoisting — выносите состояние наверх</summary>
     <ul>
       <li>Composable должны быть максимально «тупыми».
           Плохо:
@@ -326,9 +327,9 @@ request.removeObserver(requestObserver)
 </details>
 
 ## Перед отправкой на ревью
-- Проверяйте, чтобы у MR не было конфликтов. Если конфликты есть, вам нужно смержить ветку, в которую вы собираетесь мержить в ту, которую вы собираетесь мержить, и исправить конфликты
-- При повторной отправке на ревью пройдитесь по всем предыдущим комментариям и убедитесь, что все исправили, отвечайте на каждый коммент, чтобы ничего не пропустить и ревьювер сразу понимал, что вы это исправили
-- После каждого коммита выделяйте немного времени, чтобы отсмотреть все изменения, на наличие ошибок, перечисленных на этой странице.
+- Проверяйте, чтобы у MR не было конфликтов. Если конфликты есть, вам нужно смержить целевую ветку ("destination", главная/основная ветка) в ветку с вашими изменениями ("source", ваше ответвление от основной ветки) и исправить конфликты
+- При повторной отправке на ревью пройдитесь по всем предыдущим комментариям и убедитесь, что все исправили. Отвечайте на каждый комментарий, чтобы ничего не пропустить и чтобы ревьювер сразу понимал, что вы это исправили.
+- После каждого коммита выделяйте немного времени, чтобы отсмотреть все изменения на наличие ошибок, перечисленных на этой странице.
 - Обязательно обращайте внимание на [критичные для ревью пункты](#критичные-пункты-для-ревью). Ошибки в этих пунктах будут ***прерывать*** ревью.
 - После создания итогового merge request, отсмотрите все сделанные в нем изменения. Благодаря тому, что вы проверяли их после каждого коммита, это не займет у вас слишком много времени.
 - Чем чаще вы будете перепроверять себя, тем больше ошибок будете видеть и сможете не допускать их в будущем