Thread
#compose
    Michal Bacik

    Michal Bacik

    2 years ago
    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
    Fudge

    Fudge

    2 years ago
    This is a convention. It's meant to emphasize composable functions, which have different semantics than normal functions.
    Michal Bacik

    Michal Bacik

    2 years ago
    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?
    spierce7

    spierce7

    2 years ago
    you are creating a new instance of a class when you call it though, right?
    Michal Bacik

    Michal Bacik

    2 years ago
    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.
    shikasd

    shikasd

    2 years ago
    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

    2 years ago
    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

    2 years ago
    It’s not a language rule, it’s not enforced in any way
    Michal Bacik

    Michal Bacik

    2 years ago
    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.
    Luca Nicoletti

    Luca Nicoletti

    2 years ago
    You can add a check on the functions, excluding those ones annotated with
    @Composable
    Adam Powell

    Adam Powell

    2 years ago
    roughly speaking, composable functions represent defined nouns in your UI, so they are named as nouns are in kotlin - with an Uppercase leading character.
    andrew

    andrew

    2 years ago
    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
    pavi2410

    pavi2410

    2 years ago
    @Composable fun `MyButton is a function, not a class!`() {}
    How about this?
    a

    alexsullivan114

    2 years ago
    Golden.
    g

    ghedeon

    2 years ago
    @Michal Bacik
    List()
    r

    Ryan Mentley

    2 years ago
    sadly Android doesn't support method names with spaces 😞
    (mainly an issue when you want testMethods_thatArentNamedLikeThis_withAwkwardRules)
    a

    alexsullivan114

    2 years ago
    You can use spaces for unit tests though, which is nice
    pajatopmr

    pajatopmr

    2 years ago
    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!"
    Adam Powell

    Adam Powell

    2 years ago
    It would get awfully tiresome if we named all of them things like,
    declareColumn
    ,
    declareButton
    , etc. 🙂
    pajatopmr

    pajatopmr

    2 years ago
    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?
    pavi2410

    pavi2410

    2 years ago
    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
    j

    Joost Klitsie

    2 years ago
    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.
    gildor

    gildor

    2 years ago
    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
    pajatopmr

    pajatopmr

    2 years ago
    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

    2 years ago
    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

    2 years ago
    @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

    2 years ago
    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

    2 years ago
    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

    2 years ago
    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.
    pajatopmr

    pajatopmr

    2 years ago
    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

    2 years ago
    And because it's OS we could always fork Compose and create cCC (composeCamelCase) 😄
    gildor

    gildor

    2 years ago
    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