what is a good naming convention for pieces of cod...

# compose

[0xf1f1]

what is a good naming convention for pieces of code that perform a certain function. My go to term would be component, but this seems like an overused term generally in programming and can mean pretty much anything. I like the term widget and am wondering how others classify their "components". As it stands I have both conponents and widgets and I am stuck between the two. I should commit to one but Im struggling to justify either way

[Eric Vergnaud]

A widget refers to a displayable component. My advice is to not use widget for back-end components as this would create a lot of confusion.
In Java, the term bean (from coffee bean) was adopted, I personally hated it, and I don’t think anyone uses it anymore.
Depending on the granularity the term component may be perfectly suited. If it’s very small you could call it micro-component.

[Garret Yoder]

widget tends to refer to a UI element. If it's an ecapsulated set of code/classes/etc that can stand on it's own and performs a collective function, thats pretty much a module. Unless you're talking much smaller scale than that.

[0xf1f1]

I am not talking about the domain layer, I am talking about reusable UI code - composables

[Vlad]

We agreed to prefix every public @Composable with App

[Vlad]

AppText / AppCard / AppVerySpecificProductCard / AppShimmerBrush

[Vlad]

Api Level data: ApiProduct
Db Level data: DbProduct
Data level data: Product
Ui Level data: UiProduct
open composable: AppProductCard
expect/actual stuff prefixed with Platform: PlatformThing
Common Interface -> Platfrom implementations: interface Thing / ThingAndroid / ThingIos

[Casey Brooks]

In general, composables shouldn’t need a suffix of *Component, *Widget, etc. The fact that the function is capitalized already lets the user know that the function is @Composable and generates UI elements.

Likewise, shared components shouldn’t be making changes internally, but instead should expose callbacks to their parent with the requested action. For example, a shared component should have an onClick lambda rather than accessing a VM by DI internally to submit a change when clicked.

So for naming your components, just choose a name that appropriately describes the UI they generate. But in general, the Compose comunity tends to use the term “Component” for a Composable Function, instead of “Widget” like you’d see in Flutter or more traditional UI systems.

[Casey Brooks]

A prefix (such as App* described above) can be useful to help maintain your components vs the ones provided by the Material libraries, or to separate similar components by their domain in your application

[0xf1f1]

thanks for the input everyone. I like the idea of a prefix, and possibly using different prefixes to represent different parts of an app. I do think its important to create such distinctions as the code base grows and becomes more complex - backend tends to be more clearer in this regard - frontend is more messy as there are more cogs to play with and I find components being thrown around which can mean pretty much anything. The reason I suggested Widget in the context of a collections of composables is because the term is relevant to UI and immediately suggests a UI feature of some sort