The goal of having code conventions is to reach best harmony between contributors and reach a level of code style consistency so that it appears as if though one contributor was working on the code.
To reach this goal:
- We should all follow the same coding conventions
- When reviewing PR make sure that it's doesn't break conventions
- We should keep always keep these rules up to date and add any missing rules
- For action functions use present tense ex. fun onNextClick().
- Try to keep files/classes as simple & small as possible.
- Create separate files for each class (ex. Don't add the adapter and the viewHolder in the same file).
- Interfaces and their implementation : Names for the implementations of interfaces should be meaningful. Have Default as the prefix if a better name cannot be found. ex. FakeUserRepository.kr DefaultUserRepository.kt
- If the viewModel has many components in it , try and break it in sub UiModels (ex. HomeViewModel has TodayRepo's Section -> HomeViewModel can contain an instance of TodayRepoUiModel which has all functionalities/variables needed in this section and the layout.xml file for it will contain vm of type TodayRepoUiModel)
- We should avoid having the package name as concatenation between two words but if that happens that naming should camelCase with minimum words as possible (try to make the path to the package describes what this package is for) ex. data -> model -> user
- Layout files
- Use data binding
- Don't use material card view If the layout has rounded backgrounds only with no shadows, instead use drawable rounded background ex. bg_rounded_10
- Avoid passing many variables to the xml file (for example if we have item of list we should pass to it a UiModel only )
- Ids should have camel case namings with abbrevation of the view type ex. "tvTitle"
- Try and have minimum logic as possible in layout files ex. “app:goneUnless=@{vm.isViewVisible}” instead of “app:goneUnless=@{vm.condition1 || vm.condition2}”
- Drawables
- If there is a background with the same shape used in multiple places with only changing the color, don't add multiple drawables instead add one drawable and use backgroundTint to set its color in the layout
- Resources naming convention
| Element | Formula | Example |
|---|---|---|
| Drawables | $type_where_description where type is $type is bg,ic,img | bg_walkthrough_one.xml |
| Strings(belongs to a section) | where_description | walkthrough_description |
| Strings (doesn’t belong to section) | $type_description where $type is msg,title,action,error | action_cancel |
| xml elements ids | $abbreviation$Description where $abbreviation is tv,btn,et,cl | btnSubmit |
| dimensions | $what_$value where $what is padding,margin,elevation | padding_16 |
| Layouts | $type_$description where $type is activity,fragment,item(for items in list),view(for custom views),layout(for layout that included in other layouts) | fragment_home.xml |
| Color | colorWeightNumber (usually you will find the color name in the color pallet used for the designs). If you don't find the color name in the color pallet, try to reach to the UI/UX designer to provide it. | gray100,blue700 |
| Styles | Should be separated by dots and camelCase for View naming | BottomSheet.Theme |
| Text view Styles | Create a common text style if the following attributes are the only ones applied for the text: - fontFamily - textSize - color | <style name="Text.Font500.Gray500.16" parent="@style/Widget.AppCompat.TextView"> @dimen/font_size_16 @color/gray500 @font/roboto_medium_500 </style> |
- Data layer
- Note that for simplicity and to avoid having boilerplate code if the repository only contains a single data source and doesn't depend on other repositories, you can merge the responsibilities of repositories and data sources into the repository class. (This must be split if we have different data sources)