https://kotlinlang.org logo
#compose
Title
# compose
m

Michal Bacik

10/29/2019, 4:19 PM
Why are
@Compose
methods starting with uppercase, when Kotlin has lower-case rules for functions? Kotlin lists exception for factory function creating class of same name, but this is not case of Compose. And Compose uses upper-case for its functions, and it's even not tagget in IDE with warning, while ordinary functions show correct warning. https://kotlinlang.org/docs/reference/coding-conventions.html#naming-rules
f

Fudge

10/29/2019, 4:27 PM
This is a convention. It's meant to emphasize composable functions, which have different semantics than normal functions.
m

Michal Bacik

10/29/2019, 4:34 PM
For me that's unexpected, at 1st sight I'd think I'm creating new class, not calling function. Anyone can break language rules due to own "convention"? Mystery is that
@Composable
annotation mutes IDE warning for these functions. Is this hardcoded in Studio?
s

spierce7

10/29/2019, 4:43 PM
you are creating a new instance of a class when you call it though, right?
m

Michal Bacik

10/29/2019, 4:50 PM
And where is this explained on kotlinlang.org, that function creating class (many functions do) can be named out of clearly described language rules? Compose functions don't even return created class, they return Unit.
s

shikasd

10/29/2019, 4:50 PM
Kotlin team uses this approach in coroutines for
Channel
as well.
I would say that rules and guidelines are a bit different, as you can change certain coding conventions on the project level.
a

alexsullivan114

10/29/2019, 5:03 PM
Had a short discussion on Reddit about this: https://www.reddit.com/r/androiddev/comments/dm2w3c/official_jetpack_compose_tutorial/f500l3x/?context=3 tl;dr these
@Composable
methods are the only methods that can construct Composables, and they represent discreet chunks of UI logic that we'd typically see in a class before Compose, so I think it makes sense to have them as uppercase. Otherwise it's very challenging to tell what's adding UI and what isn't
r

romainguy

10/29/2019, 5:07 PM
It’s not a language rule, it’s not enforced in any way
m

Michal Bacik

10/29/2019, 5:11 PM
Well, I see it on official language website under "Naming rules" 🙂 And for my functions, it's enforced by inspection named "Function naming convention". I can disable the inspection, but still I'd break language rule with upper-case function names.
l

Luca Nicoletti

10/29/2019, 5:19 PM
You can add a check on the functions, excluding those ones annotated with
@Composable
a

Adam Powell

10/29/2019, 5:50 PM
roughly speaking, composable functions represent defined nouns in your UI, so they are named as nouns are in kotlin - with an Uppercase leading character.
a

andrew

10/29/2019, 5:54 PM
When using other frameworks like React, it also makes sense to name your components using capitals, even stateless functional components use capitals in naming as opposed to camelCase
p

pavi2410

10/29/2019, 9:37 PM
Copy code
@Composable fun `MyButton is a function, not a class!`() {}
How about this?
😂 5
a

alexsullivan114

10/29/2019, 10:18 PM
Golden.
g

ghedeon

10/30/2019, 5:32 PM
@Michal Bacik
List()
r

Ryan Mentley

10/31/2019, 3:09 AM
sadly Android doesn't support method names with spaces 😞
(mainly an issue when you want testMethods_thatArentNamedLikeThis_withAwkwardRules)
a

alexsullivan114

10/31/2019, 11:37 AM
You can use spaces for unit tests though, which is nice
p

pajatopmr

06/26/2020, 7:36 PM
It was so nice to be able to tell people: develop your apps using Clean Code names: nouns for variables and classes, verbs for functions/methods. But now I have to add: "except when you are using React or @Composable annotations with Jetpack Compose". Sounds to me like the Jetpack Compose team has been watching too many Humphrey Bogart movies: "We don't need no stinkin conventions!"
😂 1
a

Adam Powell

06/26/2020, 7:50 PM
It would get awfully tiresome if we named all of them things like,
declareColumn
,
declareButton
, etc. 🙂
5
p

pajatopmr

06/26/2020, 7:52 PM
God forbid you should get tired. 🙂
Personally, I think those are great names! They reveal the programmers intent perfectly. Isn't that what names are for?
p

pavi2410

07/01/2020, 9:18 AM
You should be able to rename the imports in Kotlin if you want. But I feel the current names are not confusing, given that they are not ordinary functions but @Composable functions
2
j

Joost Klitsie

07/23/2020, 9:27 AM
Well often, under the hood, in Kotlin you are using functions to instantiate things (like you use a flow method that basically wraps some Flow implementation) and all such things. Compose is also in that essence using functions to wrap actual instantiation of the objects under the hood. If we go to React as was mentioned in this thread, in the Kotlin React Wrapper also components are camelCase and not starting with a capital (except of course if you use a Class). So I am not sure about React on pure Javascrtipt, but for Kotlin the naming convention for React is definitely camelCase if we are talking about functions or functionalComponents. If you say compose is this cool functional UI, it should also be written as such (functions!). Functions should not start with capital case, because as a user I probably do not care what is happening under the hood, I call a function and I want to see something happening. (Of course personally I do care about what is happening under the hood 😄). As a user typing code I should see no difference between composable functions and normal functions (aside from the annotation) and I don't think that difference should be necessary.
g

gildor

07/23/2020, 10:01 AM
Row or Text also do not look as function names, so I think convention makes sense for compose functions to separate compose components from other functions
p

pajatopmr

07/24/2020, 6:12 AM
I know that when I first encountered @Composable functions anyone within listening distance heard a loud, resounding WTF! But as a few AOSP developers have pointed out, we who have this WTF moment will get over it. Compose is too important to ignore for hygiene (unclean code) reasons. So import renaming to something like @Adam Powell suggested,
declareRow()
or
declareText()
, although possibly tiresome, will not elicit quite so many WTF moments from readers of the applications or libraries using composable functions. A lot of energy is going into reacting to, explaining and justifying this unfortunate AOSP decision. But then, they are writing the code so it is their decision to make. They have heard the complaints registered and dismissed them. Perhaps they do know better than those of us having our WTF moments.
r

romainguy

07/24/2020, 6:45 AM
It’s not matter of knowing better or not, but after experimenting with different approaches (including XML-like syntax akin to what JSX does), we found that the ergonomics of the current model (only functions, with this convention) felt the best amongst all the solutions we’ve tried. We also know that, unfortunately, we will not be able to please everybody despite our best attempts.
@Joost Klitsie Recall that composable functions are not exactly like any function because they cannot be invoked in any context. So you do need to care a tiny bit about what’s going on under the hood 🙂
j

Joost Klitsie

07/24/2020, 6:59 AM
@romainguy yeah but for many people it'll just be a function with an annotation, so you as the inventor know what is happening, but many people will have no clue what is happening under the hood and probably will never take the time to find out. They just see functions. Anyway, I think you guys do an awesome job because my biggest issue this far is an insignificant naming convention 😄
r

romainguy

07/24/2020, 7:02 AM
You still need to know because if you invoke a composable function from the wrong context you’ll get a compilation error
That’s why I mean that you need to know a bit about how they work (it’s similar to suspend functions in that sense)
j

Joost Klitsie

07/24/2020, 7:07 AM
That is true. But suspend functions also start with lowercase usually ;) the suspend modifier takes care of acknowledging the context so you also don't name them differently
r

romainguy

07/24/2020, 7:10 AM
Right but that’s not obvious at the call site (so the IDE adds an icon in the gutter to tell you but that’s specific to IntelliJ).
Anyway please keep the feedback coming, it’s extremely useful to have those discussions.
👍 1
p

pajatopmr

08/04/2020, 2:40 PM
Some of us see that the AOSP Compose developers have decided not to follow the Naming Rules conventions, which is their privilege, and some attempts have been made to justify these choices. While none of these resonate for me, it would be good and appreciated to know what conventions, if any, the AOSP developers will follow and do recommend by editing that short section on naming rules to reflect what the current naming rules for Compose are and publish them on the AOSP developers web pages, perhaps including a short rationale as well.
j

Joost Klitsie

08/04/2020, 3:44 PM
And because it's OS we could always fork Compose and create cCC (composeCamelCase) 😄
g

gildor

08/04/2020, 4:09 PM
stdlib also not always follows this convention, when it has reasons do not follow it And case of compose looks perfectly valid and reasonable for me to use current convention which looks as Constructor
18 Views