kotlinlang #codingconventions

https://github.com/JetBrains/kotlin-web-site/blob/yole/styleguide/pages/docs/reference/coding-conventions.md#horizontal-whitespace This might sound stupid but developers are often doing it: I would suggest to start comment from upper case. I would also suggest to finish with dot if comment contains more then single sentence.

marcinmoskala

11/21/2017, 2:06 PM

"Use regular indent (4 spaces) for constructor parameters." I strongly agree with that, but autocorrection is still changing it to 8 spaces indent!

marcinmoskala

11/21/2017, 2:18 PM

"Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods." I was thought to sort methods by visibility and I think that it is really important because public functions are forming class interface! If someone is reading the class then he is first reading this functions. override functions should be placed before because they are even more important - they specify characteristic class behavior. I am from Android world and over there nearly all guidelines are stating that Activity/Fragment lifecycle should be placed before other public methods. protected functions are also specifying some kind of an interface - inheritance interface. This is why they all should be separated. Also all this functions should be as short as possiblie and ant their logic should be moved to private functions with behavior-explanatory names. This way someone that is reading the class clearly see that is happening and how he can use class, and he can understand it without reading implementation details that are placed in the private functions. About keeping close methods that are working together: I agree, but it is not as important as general class readability because is developer want to read specific function then he can quickly jump to it using Ctrl or using Ctrl+F on Github.

marcinmoskala

11/21/2017, 2:21 PM

https://github.com/JetBrains/kotlin-web-site/blob/yole/styleguide/pages/docs/reference/coding-conventions.md#overload-layout "Always put overloads next to each other in a class." Don't you think that it is not coherent with statement "Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods. Instead, put related stuff together, so that someone reading the class from top to bottom would be able to follow the logic of what's happening. "?

marcinmoskala

11/21/2017, 2:31 PM

This is why I am always doing like that:

fun bestStudents(allStudents: List<Student>) = allStudents
        .sortedBy { it.grade }
        .take(10)

marcinmoskala

11/21/2017, 2:34 PM

fun bigger(a: Int, b: Int) = if (a > b)
    a
else
    b

fun greet(a: Any) = when (a) {
    is String -> "Hello String"
    is Number -> "Hello Number"
    else -> "I don't know you! Go away!"
}

marcinmoskala

11/21/2017, 2:40 PM

https://github.com/JetBrains/kotlin-web-site/blob/yole/styleguide/pages/docs/reference/coding-conventions.md#chained-call-wrapping 1. I think that you forgot to use safe call in the example 2. You cannot separate ? and . in safe call co it is actually the same rule as that dot should be placed in the next line with method call

marcinmoskala

11/21/2017, 2:46 PM

https://github.com/JetBrains/kotlin-web-site/blob/yole/styleguide/pages/docs/reference/coding-conventions.md#modifiers I hope it will be supported by autostyling because it is impossible to remember xP

marcinmoskala

11/21/2017, 2:48 PM

https://github.com/JetBrains/kotlin-web-site/blob/yole/styleguide/pages/docs/reference/coding-conventions.md#platform-types What is wrong with unsafe casting there if we know that type cannot be null?

marcinmoskala

11/21/2017, 2:51 PM

https://github.com/JetBrains/kotlin-web-site/blob/yole/styleguide/pages/docs/reference/coding-conventions.md#platform-types I would suggest to use

trimMargin

to not trim intentional indent:

val a = """if(a > 1) {
          |    return a
          |}""".trimMargin()

oblakr24

12/18/2017, 9:12 AM

Quick question: enum classes naming: capitalized (Swift-style) or all-caps (Java-style)? I don't see it stated explicitly in https://kotlinlang.org/docs/reference/enum-classes.html, and I prefer capitalized (because the editor already does a good-enough color-markup to distinguish it, and all-caps looks ugly)

diesieben07

12/18/2017, 9:41 AM

There is still no official answer on how domain names with hyphens should be converted to package names. The "Java-way" of using underscores now triggers a code-style warning. 😞

pardom

12/20/2017, 5:21 PM

👏 👏 👏 @yole will the IntelliJ formatter be updated, too?

👍 1

➕ 1

nic

01/09/2018, 11:22 PM

This may be the wrong channel for this, but what would be the best way to set up a multiple property that can be set as null, but never retrieved as null. Essentially a mutable

lazy

property that can be cleared, and the next time you go to grab it, it creates a new instance of itself, so you don’t have to scatter the code with

variable?.

everywhere, since you’ll never grab a null version of it

tapchicoma

01/12/2018, 7:01 AM

Would you go with 1️⃣ :

nullableValue = NullableValue(1, 2, 3)
nullableValue?.someProperty = 4

or 2️⃣ :

nullableValue = NullableValue(1, 2, 3).apply {
    someProperty = 4
}

where

NullableValue

constructor has a lot of params.

2️⃣ 17

voddan

01/12/2018, 10:51 PM

NullableValue(.....)

a function or a constructor?

➕ 1

robin

01/13/2018, 5:47 PM

So the coding conventions suggest to put all files in the root package directly in the root folder of the application. I want to follow this, but IntelliJ makes it a bit cumbersome, because it doesn't seem to recognize that rule. When I create a new file for the package

my.root.package.subpackage

, the new file will get

package subpackage

at the start, because of course the IDE doesn't know about my root package. Right now I got it to work by adding the root package manually inside the new file template in the settings, but that seems way too hacky for me. Is there a better approach to get the desired behavior?

Dave Leeds

01/15/2018, 8:40 PM

Here’s the recommended class layout from the coding conventions document:

- Property declarations and initializer blocks
- Secondary constructors
- Method declarations
- Companion object

Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods. Instead, put related stuff together, so that someone reading the class from top to bottom would be able to follow the logic of what's happening.

I’m looking for thoughts on location of private extension properties. Would you tend to put them: 1️⃣ With the regular properties of the class 2️⃣ Near the functions that use them 3️⃣ Somewhere else (please specify)

2️⃣ 12

arekolek

01/17/2018, 2:58 PM

I’m trying to find the bit of kotlin documentation that said replacing functions with val properties is fine as long as they return the same result over subsequent, invocations, work in constant time, etc. Anyone know where that was mentioned?

uhe

01/18/2018, 9:54 AM

val foo = mapOf<String, String>()[""] ?: longAssMethodNameWithLongAssParameters(lookAtMeImSoLong = "so very long!") inlineInfixFun { return }

becomes

val foo = mapOf<String, String>()[""]
            ?: longAssMethodNameWithLongAssParameters(lookAtMeImSoLong = "so very long!")
            inlineInfixFun { return }

which doesn't compile any longer

:youtrack: 2

Czar

01/18/2018, 1:01 PM

Oooh, forgot about this channel. I have a question about class layout.

companion object

is suggested to be placed at the bottom of the class. This does not make sense to me. CO usually contains constants or stuff like

: KLogging()

so why would anyone want to hide it at the bottom? These constants and

logger

property in case of

KLogging

IMO should be declared at the top so that they be easy to reference "at a glance".

enleur

01/23/2018, 3:13 PM

“now” looks better for me

efemoney

01/25/2018, 7:03 AM

I love type hints but they dont look so great with DSL things EDIT: They dont look great in that particular case

efemoney

01/25/2018, 7:34 AM

Yeah thanks for confirming @gildor

helpermethod

01/25/2018, 9:39 AM

@efemoney Hi, what it the name of that JSON Builder DSL?

menegatti

01/26/2018, 2:31 PM

lateinit

cannot be applied to primitive types such as ~~Strings~~ and Integers

menegatti

02/22/2018, 2:48 PM

there are coding conventions here https://kotlinlang.org/docs/reference/coding-conventions.html

waqas

02/23/2018, 11:43 AM

What'e the idiomatic way checking null on multiple variables and passing those to a function which takes not nulls? I went through this -> https://discuss.kotlinlang.org/t/kotlin-null-check-for-multiple-nullable-vars/1946/8 I liked this approach but is there something better?

inline fun <A, B, R> ifNotNull(a: A?, b: B?, code: (A, B) -> R) {
    if (a != null && b != null) {
        code(a, b)
    }
}
...
    fun test() {
        ifNotNull(name, age) { name, age ->
            doSth(name, age)
        }
    }

Title

waqas

02/23/2018, 11:43 AM

inline fun <A, B, R> ifNotNull(a: A?, b: B?, code: (A, B) -> R) {
    if (a != null && b != null) {
        code(a, b)
    }
}
...
    fun test() {
        ifNotNull(name, age) { name, age ->
            doSth(name, age)
        }
    }

bdawg.io

08/08/2018, 6:38 PM

I’m really not sure why my Slack is still back in February lol. But you could also do

fun test() {
    ignoreNpe {
        doSth(requireNotNull(name), requireNotNull(age))
    }
}

View count: 3