https://kotlinlang.org logo
Join Slack
Powered by
Why are `@Compose` methods starting with uppercase...
# compose
m
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
This is a convention. It's meant to emphasize composable functions, which have different semantics than normal functions.
m
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
you are creating a new instance of a class when you call it though, right?
m
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
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
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
It’s not a language rule, it’s not enforced in any way
m
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
You can add a check on the functions, excluding those ones annotated with 
@Composable
a
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
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
Copy code
@Composable fun `MyButton is a function, not a class!`() {}
How about this?
😂 5
a
Golden.
g
@Michal Bacik 
List()
r
sadly Android doesn't support method names with spaces 😞
(mainly an issue when you want testMethods_thatArentNamedLikeThis_withAwkwardRules)
a
You can use spaces for unit tests though, which is nice
p
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
It would get awfully tiresome if we named all of them things like, 
declareColumn
, 
declareButton
, etc. 🙂
➕ 5
p
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
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
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
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
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
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
@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
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
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
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
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
And because it's OS we could always fork Compose and create cCC (composeCamelCase) 😄
g
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
562 Views
Open in Slack
PreviousNext
Powered by