First or second: ```val notificationHelper: INoti...
# codingconventions
t
First or second:
Copy code
val notificationHelper: INotificationHelper = NotificationHelper(this)
val notificationHelperTwo = NotificationHelper(this)
2️⃣ 6
e
depends on whether it's local or public
t
@ephemient what do you mean
@ephemient I thought first one is more for polymorphism... either way the example above is local
e
if it's a local val then whatever
if it's a public property then put a type on it to match what you want to expose
t
ok
what would you do for local one
e
the latter, unless the former is required for some reason (
var foo: Foo? = null
can't be written without a type annotation, for example)
t
why not var foo: IFoo? = null
e
well, mostly because I don't name anything that way. https://stackoverflow.com/a/542122
but that is a disgression from Kotlin
- most style guides will say that anything public should have a type hint - at the very least, for documentation purposes - unless it is absolutely clear from context (e.g.
const val foo = "foo"
) - anything non-public (such as local types) will depend on your taste. most Kotlin code I see leaves off type hints. sometimes you may want to add it to reduce confusion - there are a few rare cases in which the code is not correct without a type hint
t
I do not agree with you regarding your methodology of interface naming, but I respect your opinion.
y
This style of interface naming is used everywhere in the JVM community, while the `IInterface`style is used in the .NET community. i
It all just boils down to that if you get a job with Kotlin nowadays you'll definitely have to use the JVM style because companies usually have precise style guides
It's just like how you can't use snake case and everyone will be fine with it
o
Prefixing interfaces with I is really ugly ans just creates visual noise IMO. Hurts the readability
s
Don’t write Kotlin like you would C#. You wouldn’t do the reverse either.
t
@Shawn So which naming convention you use?
s
don’t tag me. I was already subscribed to the thread
second, this is covered in both the JetBrains Kotlin style guide, as well as the Android one https://kotlinlang.org/docs/coding-conventions.html https://developer.android.com/kotlin/style-guide
t
ok