kotlinlang #codingconventions

Should we request people who use :kotlin: in production to share their corporate code styles? I mean, many developers say they have their internal coding conventions, similar to what we are trying to do. We could learn some insights from them.

gabrielfv

08/14/2017, 9:48 PM

Idk if this is the right session, but what you guys think about nullable parameters defaulting to null?

fun foo(bar: Int?)

can be called like

foo()

, instead of having to write

fun foo(bar: Int? = null)

. I see people comonly reading the

as sort of "opitional" in this context, and I don't see the point of calling

foo(null)

, though makes some sense when

val a: Int? = mayReturnInt()
foo(a)

Is a common scenario

david.bilik

08/16/2017, 7:20 AM

Hello. We have discussion with our colleagues about

also

apply

usages. We have a method that needs to return some type but I would like to store instance of returned type to member property, something like

lateinit var view : View
fun createView(context : Context) : View {
  return with(context) {
    view = frameLayout {
    }
  }
}

this example would not compile because return type of view = frameLayout is unit. The variants to solve that are

fun createView(context : Context) : View {
  return with(context) {
    view = frameLayout {
    }
    view
  }
}

fun createView(context : Context) : View {
  return with(context) {
    view = frameLayout {
    }.apply { view = this }
  }
}

fun createView(context : Context) : View {
  return with(context) {
    view = frameLayout {
    }.also { view = it }
  }
}

I prefer the

also

variant because it seems that this operator was made for this usages “do something also with this expression” and

apply

is for cases when i would like to modify instance in its context. Any opinions?

Slackbot

09/04/2017, 9:22 PM

This message was deleted.

lovis

09/05/2017, 8:23 AM

please don’t

👍 6

bj0

09/09/2017, 2:21 AM

#1 or

list?.isNotEmpty() == true

👍 8

karelpeeters

09/09/2017, 3:22 PM

One of the common solution to

null

-related problems in Java is to return a "default value", and this works especially well with collections, there's rarely a reason for them to be null. Just make your mehods return empty collections instead.

Dmitry Kandalov

09/15/2017, 10:08 AM

Following up the conversation above about string concatenation formatting, I tried using

on new lines as @gabrielfv suggested:

foo("one"
    + "two"
    + "three")

only to find that it doesn’t work with

return

, e.g. the following doesn’t compile because of

on new line:

fun bar(): String {
    return "one;"
        + "two;"
        + "three"
}

I’d argue this means that

and

.plus()

are already different enough to have different formatting 🙂 /cc @kevinmost

dimsuz

09/15/2017, 3:26 PM

another thing is that it can be an rhs, and then the first variant get's kinda ugly

vlastachu

09/20/2017, 4:33 PM

Hi all. is it possible in android studio to align constructor assignment?

CPTViewModel(
        selectionType = null,
        taskName = task.displayName,
        projectName = projectInfo.project.name,
        customerName = projectInfo.customer.name,
        isTaskVisible = true
)

CPTViewModel(
        selectionType = null,
        taskName      = task.displayName,
        projectName   = projectInfo.project.name,
        customerName  = projectInfo.customer.name,
        isTaskVisible = true
)

:rage1: 1

:no_red: 4

dimsuz

09/25/2017, 11:19 AM

Maybe someone here will know what this suggestion is based on? Some specification/KEEP/etc? Where could I read more about this,

gildor

09/27/2017, 5:33 PM

val url = it.imageUrl ?: return null
val link = it.resizerlink ?: return null
val width = it.imageWidth ?: return null
val height = it.imageHeight ?: return null

return Image(url, link, width.toInt(), height.toInt())

3️⃣ 14

:kotlin-flag: 3

gabrielfv

10/11/2017, 7:33 PM

How would you guys recomend to use elvis operator on long expressions with line breaks?

val a = foo.computeBar(Baz::class.java).fetchFirst() ?:
        return@thisComputationFun

val a = foo.computeBar(Baz::class.java).fetchFirst()
        ?: return@thisComputationFun

or none at all? The IDE has recomended me to do this in place of the classic

if (a == null) return@thisComputationFun

miha-x64

10/12/2017, 4:31 PM

Destricturing. Default indentation:

val (
        distributor,
        items,
        shippingMethods,
        addresses,
        preferredAddressId
        ) = argument

I propose:

val (
        distributor,
        items,
        shippingMethods,
        addresses,
        preferredAddressId
) = argument

michaelsims

10/22/2017, 5:31 PM

mainThreadScheduler.executeOnThread(Runnable {
    result.errorResult.let {
        if (it == null) {
            taskCallback.onSuccess(result.successResult)
        } else {
            taskCallback.onFailure(it)
        }
    }
})

yole

10/23/2017, 7:51 AM

@joscha.alisch no. it’s perfectly fine to define extension functions for your own classes too, if the code is useful only in a limited context and is not worth cluttering the API with

👍 1

raulraja

10/24/2017, 11:58 PM

1. If the first parameter is like in 2. Also last parameter closes with

is what I find more readable

uhe

10/25/2017, 8:08 AM

1️⃣ and 2️⃣ ... properties on a new line to avoid too much indentation but

) {

on the same line as the last property because it's just a wasted line otherwise

👎 1

👍 2

raulraja

10/25/2017, 10:02 AM

This brings up the question. What's the equivalent of something like scalafmt in Kotlin?

marcinmoskala

10/25/2017, 3:33 PM

@bdawg.io I am confused because I see 3 options and 2 numbers o.0 I would like to vote for 3️⃣

bamdmux

10/26/2017, 5:27 AM

From 1.1 you can declare them outside the sealed class but in the same file. I prefer it this way

Sean Corfield

10/27/2017, 6:02 PM

What about those folks who don't want to use IntelliJ? 😒imple_smile:

zredna

11/06/2017, 2:14 PM

What is the recommended way to declare private constants only used by a single class and why? 1. At the file level as private const val AWESOME_CONSTANT 2. Inside the class as private val awesomeConstant 3. In a companion object as private const val AWESOME_CONSTANT 4. Something else

1️⃣ 4

yole

11/14/2017, 1:34 PM

no, there isn’t one and we have no plans to publish one

😢 1

liminal

11/19/2017, 2:18 PM

is there a cleaner way to do this?

fun isValid(): Boolean = noteText.isNotEmpty() && noteText.isNotBlank() && noteText.length > 3

to avoid repeating noteText several times? thanks

enleur

11/19/2017, 2:19 PM

noteText.trim().length > 3

👍 1

marcinmoskala

11/21/2017, 1:49 PM

"Placing multiple declarations (classes, top-level functions or properties) in the same Kotlin source file is encouraged as long as these declarations are closely related to each other semantically." I totally agree for top level functions, properties and small objects. But people are often doing things like whole data model in single file and it is really hard to operate on that. It makes harder to find classes when files are not named with their names.

marcinmoskala

11/21/2017, 1:49 PM

https://github.com/JetBrains/kotlin-web-site/blob/yole/styleguide/pages/docs/reference/coding-conventions.md#source-file-names I often hear that files with extension functions should be named with "Ext" suffix.

marcinmoskala

11/21/2017, 1:52 PM

https://github.com/JetBrains/kotlin-web-site/blob/yole/styleguide/pages/docs/reference/coding-conventions.md#naming-rules "use camel humps (org.example.myProject)." - If we follow Java convention (and I will strongly support that) then we should not use upper-case in package name https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

Slackbot

11/21/2017, 1:58 PM

This message was deleted.

Title

Slackbot

11/21/2017, 1:58 PM

This message was deleted.

yole

11/21/2017, 2:18 PM

this is an endless argument, and I’m not going to begin another round of it. suffice to say, Google’s Android style guide also has the same convention, and I’m not going to either contradict them or try to convince them to change their style guide

marcinmoskala

11/21/2017, 2:24 PM

This is why I would just avoid making any statements about it and I woild let developers do it how they want. Note that Kotlin/Native is opening Kotlin to lot's of new environments and platforms (Python, R etc) and they will not be happy if developers will be forced to change their naming habits.

yole

11/21/2017, 2:25 PM

following that logic we might as well give up on the style guide altogether. and the community has clearly stated that one is needed.

marcinmoskala

11/21/2017, 2:59 PM

It is not a point. Conventions are needed but not just for making conventions. They are needed when there is some purpose behind them. I feel that this rule is not improving anything. Stating that something is constant says nearly nothing - most properties in Kotlin are read-only.

Let's say I want to specify read only property with Gson. Do you want me to do it like that:

val gson = Gson()

or like that:

val GSON = Gson()

I would strongly prefer first option and I am pretty sure that this is how Gson was defined in KotlinConf-app

Andreas Sinz

11/21/2017, 3:06 PM

@marcinmoskala Gson() is not a constant

marcinmoskala

11/21/2017, 3:48 PM

@Andreas Sinz It is clear, but isn't it a top-level property holding data? I think that this is not clear

Andreas Sinz

11/21/2017, 10:07 PM

@marcinmoskala At the beginning it starts with

Names of constants

properties that hold data

probably can be confusing

marcinmoskala

11/22/2017, 6:15 AM

yole

11/22/2017, 8:32 AM

the Android style guide contains a fairly elaborate definition of what is and isn’t a constant. we might just copy that

➕ 2

marcinmoskala

11/22/2017, 3:11 PM

After consideration I think that your argumentation is good and this is why I deleted my suggestion. Although some clarification might be useful.

yole

11/27/2017, 3:14 PM

I’ve clarified the text based on the wording in the Android style guide

👍 2

View count: 4