Exit Full View

Good Names are Good

We all know (I hope) that naming classes and variables correctly is important. A badly named variable makes your code unreadable.

If a var is a variable, WTF is a val ? Let's be clear, it is not a value. It has a value, but it is not itself a value. Values don't have names, vals do.

IMHO, this isn't a trivial thing. I truly believe that names are important, and the fact we don't have a name for a val is bad.

I want a word that means "A named memory location which can be read, but not re-written".

If we pick/invent such a word, it should be applicable to all languages (which have such a concept).

Can you think of a good name? The best I've come up with is invariable. Which can be shortened to inv.

Function vs Method

We have two words with precise meanings, and then Kotlin comes along and uses the keyword fun for both of them! Ahhh!

Yes that pisses me off.

IMHO, it would be much clearer if we used fun for functions (including extension functions), and meth for methods.

Java is just as bad. It has "static methods". They aren't methods, they are functions! Were the designers too proud to admit that Java isn't a "pure" OO language?

And I can't stop myself from slagging off Java a bit more. WTF is static about static methods?

C uses that keyword to mean two completely different things :

  • static local variable - a good name, although a weird concept.
  • static global variable - a terrible name, which really means "private".

Java's static keyword doesn't correspond with either of those. So a static method gets a score of 0 out of 2.

Summary

Learning to code is hard enough, without artificial road blocks.

Language designers are important leaders of our profession, and they should take greater care to name things correctly.

If I had my way, I'd deprecate val and introduce two new keywords inv and meth. Start issuing warnings after 5 years, and errors after 10 (with a compiler option to turn them off).

Okay, perhaps pragmatism would get the better of me. New keywords will break existing code. We are stuck with badly named keywords till Kotlin itself is replaced with something better. <sigh>