Converting to Kotlin

IntelliJ offers a series of features targeted at Android development, among these is the ability to quickly create Android Components:

For instance, selecting to create a new Activity will generate the corresponding XML layout, source file and update and the application manifest. Quite useful. The problem is though that the source generated is in Java, which isn’t an issue of course unless you’re working with Kotlin. However, you can easily work around this. Simply use IntelliJ’s helper to create the necessary components, then select the generated Java file in the Project window and from the Code menu click on Convert Java File to Kotlin File (there’s a different shortcut depending on your keyboard layout).

All this functionality is available in both IntelliJ Ultimate as well as the free OSS IntelliJ Community Edition, the same one Android Studio is built on.

I’d be looking for another job. Not because of having to go the office everyday, but because they’re trying to solve the wrong problem. It seems like they feel if people are bound to a schedule, working in an environment where they can be controlled, everything will sort itself out.

Were I work, people set their own schedules. Whether they’re working from home or in an office. There are no office hours, no controls, no micromanagement. And yet it works. It works because of two main cultural values: respect and care.

Respecting the individual. Caring for the individual

Respect is not limited to treating people politely. It is respecting them as individuals, it is understanding that each person is different, works in different ways, has different challenges or circumstances that need to be dealt with. However, it is more than just acknowledging it, it is doing something about it. It is caring enough to want help.

Applying these values in a work environment between employer/employee, between team members is what makes the difference. And it makes a very important difference.

An employee needing flexible hours can either be faced by an employer who makes excuses about why it won’t work out or someone that is willing to help accomodate the employee. Helping this person out shows them that their employer cares enough about them as an individual. And if there is respect, this behaviour then becomes reciprocal.

These values needs to be applied to all aspects: between colleagues, teams, an individual’s work, the collective work, the project and on a more global scale, the goals of the company.

The culture of mistrust.

It is the feeling of respect and caring for each other, and the things we do that builds up and creates a relationship of trust.

Mistrust on the other hand emerges  as soon as you ask someone to clock in/out. When you ask them for detailed daily reports, you’re saying that you’re not sure if they’ve actually been working all day.  When you micromanage, you’re telling them, that not only do you not trust them, but you don’t respect them enough to be more than an insignificant cog in the machinery.

This creates tension. It leads to parties disrespecting each other. And as this happens, people stop caring. Why care about something you don’t respect? As a result, efficiency drops. Employers lose. Teams lose. The company loses. The individual loses.

It becomes another 9 to 5 job for a pay check.

Perks don’t buy respect 

A spokesperson for Yahoo writes:

[Marissa] Mayer is happy to give Yahoo employees standard Silicon Valley benefits like free food and free smartphones…”

Free donuts, constant flow of coffee and sodas are great. But if there is no respect, it means very little. Perks alone don’t buy respect or fulfil individuals. They are the icing on the cake. But there needs to be a cake.

Taking freedom away from people by forcing them into a 9 to 5 schedule on-site and then saying you’ll give them a mobile phone is not going to solve anything.

Care for people. Respect them. Give them the freedom to work. They’ll give you their best.

You’re running an OSS project* and someone makes a pull request. You’ve got two choices:

• Merge and Pray
• Pull to local branch, build, run tests and merge if all OK

What do you do? Well, what is it going to be?

I know what I’d like to do, and GitHub makes it so so tempting:

But unfortunately I go with the second option.

That’s a pain, specially if you do a quick code-review and things look decent. Yet you still need to make sure that it builds and all tests pass.

Well, luckily for me, and my ability to continuously interfere in conversations, I found out that there is a better way. And what’s even nicer, is that it’s also possible with TeamCity.

*This applies to non-OSS too

Automatically Building All Pull Requests

What I want to do is have TeamCity automatically build all Pull Requests for me of my main repository, and notify me if it is successful. And I want this to happen without me having to configure every single fork as a repository in TeamCity, because like that, it wouldn’t be manageable. Here’s a diagram explaining it:

This will drastically improve the workflow since we no longer have to manually create a local branch of the pull request, check it, build it and only then merge it.

Configuring TeamCity

Setting up TeamCity to do this is really simple. It actually only requires one thing: configuring the Branch Specification under the VCS root:

Let’s see what this means and why it works. When a pull request is made, GitHub automatically creates a reference that holds the pull request as well as one that is a merge with the master branch. What we’re saying to TeamCity is to monitor this branch, in addition to the main branch. In this syntax, pull refers to the pull request. The * refers to ANY pull request, and the merge indicates that we’re interested in the pull request merged with the master branch. This means that when TeamCity builds, it will build the branch that was merged. If we want to build the branch, without merging, we could use the following:

+:refs/pull/*/head

So to recap, adding merge builds the result of the merge, and adding head, just the pull request without the merge.

The result of these builds show up in TeamCity like so:

where the number denotes the pull request. Now, we can actually make this a bit nicer by allowing us to see whether the particular request was the result of a merge or just the branch itself. For that, we can specify the following in the Branch Specification

with TeamCity now indicating whether this was a merge or head:

In addition, TeamCity also provides us with a Dropdown, where we can filter all the different pull requests:

Seeing notifications on the Pull Request

As this is a normal build, like any other build, we can configure TeamCity to receive notifications via email, tray icon, etc, both on successful builds as well as failed builds. However, there is one other thing that we can do: see the result of the build on the Pull Request page on GitHub. In order for this to happen, we do need to install a plugin for TeamCity which currently doesn’t ship out of the box. This plugin, written by Eugene Petrenko uses some hooks GitHub provides to add notification information on the Pull Request page.

To install it, download the plugin as a zip file and place it in the plugins folder of the server and restart the server.

Once that’s installed, we can now display build status information on the GitHub pull request by adding a Build Feature to our Build Steps:

and filling in some simple configuration parameters:

And with that, we can see the status on the Pull Request page on GitHub.

* If you’re running your OSS project on TeamCity at CodeBetter, you now have this plugin available.

Summary

Although my example was based on TeamCity 8.0 which is currently in EAP, this feature also works with TeamCity 7.1.3+ (and even previously covered by others). The examples are also based on OSS projects, but you can apply the same workflow to private repositories also, hopefully making things a little bit easier.

In this code, given, on and it are all functions.

Kotlin allows top-level functions to be defined (without the need for them to belong to a class). As such, we could merely declare these functions in a single file as below:

At first sight it might not seem like a bad approach, but it is. The problem is that you cannot prevent someone from calling the code like so:

or even:

or any other weird combination for that matter.

This means that we would now have to put in additional runtime checks to verify that things are called in the correct manner; context has been set up before the action, the action has been executed before the assertions and so on and so forth. Pain.

Extension Function Literals

We’ve already seen that Kotin has extension functions, similar to C#. We’ve also seen that we can define extension functions as function literals:

Combining this with high-order functions, that is a function that takes a function as a parameter, we can do:

given is still a top-level function. However, the diference is that on and it are no longer top-level. Instead, we’re creating three different classes: Given, On and It.

Let’s take a look at the Given class. This class has a method that takes two parameters: a string, which is the description and a second parameter which is the extension function literal we’ve been talking about:

The parameter is an extension function on the On class, which takes no parameters and returns no value (Unit in Kotlin – void).

We repeat the same pattern with the On and It classes. By doing this, we now enforce a certain flow at compile time and prohibit out of order usage.

You can see also in the code, that the It class contains a series of assertion methods, exactly where they belong.

Summary

We can see that with some simple extension function literals, we can easily impose a series of restrictions on our DSL’s. Of course, in this case, the example is quite straightforward but the same thing can be applied to designing other DSL’s such as HTML builders et al.

[Thanks to @orangy for highlighting the issue and refactoring of Spek to this]

The problem is, that not everybody seems to see the button. In addition, in a world of Like and +1, what tends to happen is that we end up with a lot of comments like this:

So how should we fix it? Make the vote button bigger? Place a couple here and there? I asked this question on Twitter a few days ago and one of the more common responses was:

“Can’t you add a feature to YouTrack to make +1 add a vote?”

Workflows save the day…again

Well, good news is that we can. But the even better news is that we don’t need to add a feature, and consequently you don’t need to wait for us to ship this feature if you’re also encountering this problem. We can actually solve this using Workflows. If you’re not familiar with workflows, think of it as a way to get YouTrack to pretty much do whatever you want.

The workflow is actually quite simple:

With a simple rule like the above, attached as workflow to your project, any +1 comment will now be interpreted as a vote and a nice message displayed to the user.

Just write the workflow, upload it to the server and attach it.

Shipping out of the box

As of YouTrack 4.2, this workflow will already ship out of the box. Until then, and using your current version of YouTrack, you can create the workflow, attach it and you’re good to go.

Here’s a short introductory screencast that gets you up and running.

This post is about the overall experience with the phone. It is not about pointing fingers. From a user’s perspective, I don’t care if it’s a Nokia issue, an Operator one, Microsoft’s, Windows Phone Team or last but not least, App developers. I’m describing my experience as a user.

I also realise that many people might have a completely different experience to mine, and that’s fine. It might be I’m too picky or just have bad luck with electronics (does happen). Having said that, let’s move on.

Disclaimer: Maybe some of the issues I point out in this post are user error or sheer ignorance. If they are, please enlighten me. I’ve still not decided 100% if I’m going to stay with iPhone or switch back.

The Hardware

The device itself is actually very nice. It’s a slick, thin design and despite it’s dimensions, it does not feel uncomfortable to hold and have in your pocket. As Dan North says, it’s the thinness that matters, and I tend to agree. It has a nice screen size and having an external button to activate the camera and take shots feels very comfortable and natural. The camera itself is fantastic. Great quality video and pictures.

My device is a Developer edition, so it didn’t come with any charger other than an extremely short USB cable. Not much more to comment on the hardware, other than there was no headset. Not sure if the retail version comes with a decent one which includes a controller much like the iPhone. It is definitely something I missed having.

Volume Control

The downside of the hardware is not having a Vibrate/Mute button like the iPhone does. In addition, placing the phone on Vibrate requires 3 operations: Press the lock button, press the Volume down or up button and then click on an icon to toggle between Vibrate or Ring. As someone with a 10 month old baby or having to use the Vibrate button quite frequently “on the job”, this can be cumbersome.

What is however much more annoying is that there is no separation of media from ring volume. If you want to hear the phone, you’re going to pop your ears out listening to music. There is only a single volume level which applies to Video, Audio, Notifications and Ringer. Honestly I don’t know why they’ve not thought of this.

The Keyboard

Initially the keyboard seemed fine. I was able to type, except for one,minor,issue,and,that,is,that,I,kept,pressing,the,comma,key,instead,of,the,spacebar. No matter how much I try, I can’t avoid it, to the point that lately I was avoiding using my right thumb to hit the space bar. Maybe I have a thick thumb. Don’t know. Other than that though, no real issues in key spacing or other.

Spellchecker

Try and type Hell on the iPhone and you’ll always end up with He’ll. Can be annoying. I was somewhat relieved initially that this wasn’t the case with this phone. What it does offer is word completion. If it feels you’re writing a word incorrectly, often the first word on the autocomplete list is in bold, meaning that it will automatically replace the word you’re typing. It claims that it learns from your typing and offers suggestions based on it.

To be honest, I’m not sure how well this works. It doesn’t seem to offer a lot of autocorrect suggestions, and some that I’d really like it to offer, it does not. For instance, on the iPhone, every time you type i, it will interpret it as I. When I type Ill, it will replace it with I’ll. Not here. You type i, you have to explicitly correct with I. Same with Ill. Dear Windows Phone team, there is rarely ever a time when I type i and not mean I.

The upsides to the spell checker not being over protective is that it doesn’t autocorrect too often, which I find can be useful when alternating between two languages (in my case English / Spanish) and not having to constantly switch keyboard layout. In addition, sometimes (I’ve still to figure out when), a + sign appears next to a suggestion, allowing you to add it to the dictionary.

Form Navigation

This one is really a fail in terms of usability, or I’m doing something completely wrong. While filing in a form on the browser, on the iPhone, you are normally provided with two additional buttons right on top of the keyboard: Next, Prev allowing you to easily navigate to the next or previous field. On WP8 you don’t get that. And this can be really problematic since as the keyboard overlaps half the screen, you often cannot click on the next field to move fields. In fact, this problem occurs on native applications also. Sometimes I honestly don’t know how to navigate back and forth between fields.

Battery Life

Used extensively, the battery lasts me around a day. That is when I don’t get the sudden death feature, whereby the indicator displays half-charge and the phone just dies on me.

Links and Discoverability

Most applications use regular text as action items, not buttons. The problem is that there’s nothing that differentiates a link from regular text on the screen. And while often an action is apparent, many times I find myself clicking on different text items wondering if something’s going to happen. Of course, this isn’t aided by the fact that some application designers think it’s good to hide actions under pictures or avatars et al (Skype comes to mind). Not the most discoverable interface at times.

Live Tiles

One of the main features of the Windows Phone and a big selling point are Live Tiles. And they are fantastic. Of course, after the first couple of days, when the new factor wears off, you’re left with the annoyances of caching issues, by which I mean tiles not refreshing accordingly. I’ve had this occur with WhatsApp among other applications.  While not getting the latest headlines on a live tile isn’t detrimental, missing out on messages does put you in an compromising social position whereby you now have to explain that you really weren’t ignoring people.

I think that the Live Tiles have a lot of potential, but unfortunately many applications don’t take much advantage of them. Also, applications don’t offer much in terms of customisation. For instance, with Skype, it displays on the tile the number of notifications and you cannot switch it off. The only way to do so is to remove the tile from the main screen.

People Hubs

Another central feature of the phone are Hubs, the idea that you connect different aspects of a person into one central place. For instance I have a live tile for my wife. I link Skype, Cell number, SMS et al all under her contact. Idea is that everything is now displayed on that tile. Fantastic. Unfortunately, at least for me, not everything works. I only manage to see SMS’s and phone calls under the tile. Not sure if this is a Live Tile cache problem again, or a lack of proper implementation from the intervening apps, but ultimately, it doesn’t work as expected.

In any case, even if this were to work correctly, I’m not sure that I’d want anyone other than my wife on the front screen in a tile. I honestly don’t picture my colleagues or other people representing an icon on the screen. There is the concept of creating a group of people and having them in a tile, but again, that seems to suffer from the same issues as a single person.

Having these people hubs also does away with some common features we’re used to in other phones, namely favourites. For instance, when clicking on the Phone application, there’s no Favourites. On Windows Phone it’s hubs. You want favourites, create a hub and link contacts up.

The Apps and the Store

When I first received the phone, I immediately tried to install all the apps I had on the iPhone. To my surprise, Skype wasn’t available, which is quite disappointing considering that Skype now belongs to Microsoft. It did arrive several weeks later and to be honest, except for the live tile issue, the overall experience with it is good. However, other apps are quite disappointing: 1Password crashed (apparently now it’s fixed but still doesn’t work for me). WhatApps has issues of not receiving messages and/or updating the live tile. Viber doesn’t offer voice, only messages. In addition, the overall choice of applications is not that great. Yes, if you want RSS readers or background images, there are plenty.

When it comes to the actual quality of the applications, not too impressive.A lot of crashes, a lot of hangs, some awful user experiences. This is somewhat unfortunate since the ecosystem contributes significantly to the success of the device.

One feature I do like is the ability to search for an application and install it from the store without explicitly going to the store. When launching an application you can search for it by using the Search feature. If it doesn’t find any matches, it provides you the option to search the store. Installing applications from the store is straightforward. I’ve actually not bought any applications so cant’ comment on the payment experience.

The Hangs

Apart from random application crashes (specially Twitter), I’ve had several hangs of the phone, causing me to switch it on and off.  Others don’t seem to suffer this problem, so it might be just me (again).

Mail

The mail application is OK, nothing special or any feature that really stands out. Gmail works fine, and I could sync my account, including contacts and calendar successfully. However, that’s going to change.

Tap and Send

Apparently the phone has a Tap and Send feature where you can get close (or Tap?) another phone to share information. Unfortunately I’ve not experienced this myself since I haven’t found anyone I can tap (the phone) with. NFC also provides wireless charging, but again, not experienced it personally.

Music

Nothing really stands out when it comes to the Music application. It’s quite decent, with album view, quick play, etc. However, one feature that is lacking is the ability to create playlists directly from the phone. This sucks, specially when you’re on the road, on a plane, on a train, when you actually have time to sit, listen, create a list.

Connectivity

When it comes to Internet Sharing, very easy. Switch it on and you have a WAP. One nice feature is that it automatically switches off the sharing if nobody is connected after a couple of minutes. Had no issues connecting via PC or Apple.

Can’t say the same about BlueTooth. For the life of me I couldn’t get it to work with my car. I’ve had no issues with two iPhones or two Androids, but Windows Phone doesn’t seem to like Toyota Auris. Additionally, the USB outlet of my car also isn’t apparently powerful enough to charge the phone.

For Data, the phone provides 3G and H+ and both work fine. I did have to explicitly set up the configuration for my telephone operator in Spain (Movistar) and much like the anything other than iPhone, hooking on to Movistar WiFi zones requires sending an SMS and getting a password. This is an operator issue I’m assuming, but again, the overall experience is not as smooth as with the iPhone / iPad whereby it automatically detects you and logs you on.

WiFi also seems to work OK except that every time the phone locks, it loses configuration for open WiFi’s that require you to log on via browser. Again, annoying.

Editing

The editing and positioning of the cursor is kind of strange in comparison to other phones. When positioning the cursor, you don’t get the magnifying glass. Instead you get a cursor offset from your actual finger’s position by about a couple of mm’s. You then move your finger around to position it. For a while I didn’t realize how this works, until finally I moved my hand further down to get the cursor back on screen. Somewhat strange, and on the fence about it. Copy/Paste operations I’ve found a tad cumbersome in some occasions,  specially with autoselect (i.e. click on a link and it autoselects it).

Summary

I switched to the Windows Phone with an open mind and tried it out for over a month. I’m now back to the iPhone and one of the reasons is to see if I actually miss anything from the Windows Phone (while I thought I’d really miss out on the screen size, I haven’t that much). The one thing I do miss is the Home button actually working (yep I have this issue).

Of course, many of the issues I’ve highlighted might boil down to minor things that need ironing out, a few rough edges here and there you might say. The problem is however, that this is not the first generation of Windows Phone. And to enter a market that is already dominated by two major players, you not only have to disrupt it by offering something fantastic and new, but you also have to make sure it’s perfect. Unfortunately as it stands today, for me at least, Windows Phone 8 is neither.

The setup itself is extremely simple, and we’re going to walk through it, and additionally add some more goodies in the mix.

Activating .NET Inspections in TeamCity

Adding ReSharper inspections to the build process is merely adding the Build Step named Inspections (.NET). The only parameter required is the Visual Studio Solution file

If we do not specify a Custom settings profile path, TeamCity takes the default ReSharper settings for code inspections. However, we can configure these to match our own/teams criteria. This is done via Options | Inspection Severity. We can change a specific setting severity, for instance, that of using String.IsNullOrEmpty

and save the settings to the Team Shared file. This then saves the settings in a file named {Solution}.sln.DotSettings which is normally checked in to source control so that it automatically applies to other team members when the solution is opened in Visual Studio. We can use this same settings file to indicate custom inspection settings for TeamCity

Analyzing results

When the build step runs, TeamCity generates a navigable report for us to analyze inspection results

We can navigate through the inspections for the entire project or a specific namespace. Inspections are grouped by Category, Issue Type and the corresponding files on the right pane. We can even navigate to the actual file by clicking on the line number. For this though, we need to have Visual Studio and the TeamCity plugin for Visual Studio installed (if you do not, clicking on the link will prompt you with a dialog box to download and install the plugin).

The checkbox Inspections with new problems only is used to highlight only new issues since the last build run. The numbers in bracket (+1 –1) are the variance since the last run.

Taking action based on inspection severity

One of the main benefits of adding inspections on the server-side is to put some level of code quality in place, whereby we can have the build process take action based on a series of conditions. For instance, we might like to have a build fail if too many warnings or errors are detected.

Under Build Failure Conditions in the Project Configuration window, we can add a new Build failure condition:

We select Fail build on metric change and then indicate whether we want a build to fail based on warnings or errors. In our case we’re going to select errors and have it fail if it is more than one.

It should be apparent that if we want inspections to have an impact on the status of our build, that is, have a build fail, we can only do so based on Warnings or Errors. Therefore, Hints and Suggestions cannot be used. As such, when configuring inspections severity in ReSharper, we should take this into account.

If we now run our build again, it should fail as the number of errors are greater than one. Below is the output of the same input and inspections, but one run with the Build failure condition and the other without it.

Checking for copy/paste code

Although strictly speaking, this isn’t related to ReSharper, but since we’re talking about code quality in the build process, it makes sense to also mention that TeamCity can check for code duplication.

Much like before, activating code duplication is simply a matter of adding a new build step, namely Duplicates finder (.NET). We can indicate the folders to ignore, whether we want to take into account namespaces, type names, as well as a few other options.

The output is a nicely formatted navigable screen which allows us to go through the different files and see a side-by-side comparison of what TeamCity has detected as duplication (resized below for space limitations)

And as expected, we can also fail the build if we have too many code duplicates

Summary

It is refreshingly simple to add code quality detection features to the build process and have a build fail if something that shouldn’t be in production code slips through. The next step would be to provide Custom Patterns, which currently are not supported. If you feel this is a feature you’d like, let us know, and as always, any and all feedback is welcome.

I’m not going to argue or layout the benefits of why putting in place an automated test system for your code is a good idea. I think we are well beyond that discussion and most of us accept it. As such, let us assume that we have unit tests.

Test First or Test After

In order to get these unit tests in place, we have to write them. Here we have two different approaches: test first or test after. In other words, we can either write code and then test or write a test and then implement the code.

With the first approach, that is, writing tests after writing the code, we not only face the challenge of writing a test for something that we perceive as ‘working’, but we also run the risk of creating code that is somewhat hard to test. As the project progresses and the deadlines approach, we tend to drop or ‘defer’ some tests and start to rush more into getting code out the door. After all, what is a perfectly tested codebase if it is not shipped?

What potentially ends up happening, which I’ve seen far too many times, is that we never get round to implementing the missing tests, much like we do not normally go back and pay for technical debt. And of course, this means that our code is at a higher risk of malfunctioning and ultimately costing us money.

If we take a test first approach, we are forced to write a test prior to writing the code. As such we have the test in place. We don’t need to come back later after writing the code to write the test. In addition, since we write the tests first, we can immediately solve any issues that lead to untestable code, after all, we’re writing the code we want to test, so why write it in a way that is not testable if we know beforehand? It’s not like we have written all the code, then come to test it and realized, oops! Yet this is something that does occur in test after approaches and often requires even more effort and thus easier to ‘justify’ skipping a test or two.

Taking the TDD route, we have less chances of ending up with code that is not tested. We have less risks of leaving a test for later, a moment that never arrives.

You could say that it’s a matter of discipline, that just like we commit to TDD and always writing tests first, we can also commit to writing tests after. And I agree, we can. But reality shows that we don’t. Psychologically, there is less chances of us writing a test for something that is ‘working’ than for something that is not.

TDD as an insurance you took out

Now the reality is that TDD isn’t actually about testing as much as it is about design. It is not about test first versus test after. It is about trying to better understand a system, about trying to break things down into pieces our mind can cope with (divide and conquer). It is about specifications. And while I dislike using the word side-effect, the unit tests that emerge from TDD not only guarantee the correct implementation (different to understanding correctly the specification) but also, and more importantly, serve as a regression test.  You could therefore think of a unit test in TDD as having three different life forms.

This regression testing is where the analogy to insurance policies comes in, cause even f you don’t believe in the benefits of TDD as a whole, at least consider that it is like that insurance policy which you did take out on the first day, as opposed to the one you kept delaying until it was too late.

Part I: Getting things set up
Part II: A primer on classes
Part III: Wrapping up classes
Part IV: Adding functionality

All the goodies you’d expect

Up to now we’ve seen how to work with classes and only slightly touched on the subject of functions in Kotlin, reason being that functions deserve their own section, as they play a very important role in Kotlin and expose a lot of the potential the language offers. Let’s dive in a bit more now.

Functions in Kotlin are declared using the keyword fun. By default, if we do not specify a return type, Unit is returned which would be the equivalent of void, although we do not need to explicitly indicate it. Parameters, much like constructors of classes that we’ve already seen, follow the Pascal convention of name colon type.

If you’re coming from a C# background, expect pretty much everything you have in C#, including:

Optional parameters

The last parameter being passed in to the logMessage function is optional (like C# they always need to be at the end). If nothing is supplied, a default value is used. In this case, it’s using the current date time by instantiating an instance of Date.

Named parameters

We can also call functions using names to reference parameters, making the order of which we pass arguments in irrelevant

Variable number of parameters

If we want to pass in a random number of arguments, we can prefix a parameter with the keyword vararg which by default creates an array of the type of the parameter

As such the example above would be an array of Integers.

Statics in Kotlin

The concept of static methods doesn’t really exist in Kotlin as functions can be declared as top-level. As such, we can define a series of functions in a module and then have access to all of them by merely referencing the module. Therefore there’s no real need for statics. We can also declare one function local to another, much like in Pascal.

Reducing amount of code with single-line functions

If a function consists of single line of code, whether or not it returns a value, we can omit curly braces and reduce a little bit the number of characters. For instance, the previous logMessage could be written out as:

The compiler can infer the return type, so even if we were to return a value, we wouldn’t need to explicitly declare it.

enabling fluent code

Kotlin allows us to reduce some of the noise that is usually associated with certain programming languages, by offering a series of features that enable us to write code that is somewhat a bit more fluent, or closer to natural languages.

To begin with, any function that takes two parameters can be called in infix notation. This means that we can do things such as:

where plus and equals are functions that take two arguments (and defined as single-line for brevity):

Kotlin also allows extensions functions, thus allowing us to extend a class with functionality without having to inherit from it. If you’re a C# programmer, you’re familiar with extension methods. Only difference is that in Kotlin, the declaration is more succinct:

This adds a new function to the String class called console (takes no parameters). Inside the function, we can refer to the object itself using the keyword this. Notice how as opposed to C#, we do not have to create a static class, a static function, or pass this as the first parameter.

And of course, extension functions can also be called using infix notation. By defining the extension then to be:

we can write code like this:

not that I’m saying we should write the code above, but you get the point. It opens up many possibilities.

Adding function literals and high-order functions to the mix

Functions in Kotlin can take other functions as parameters. Combined with function literals (or lambda expressions), it allows us to write the following:

Here we have a function callFunctions that takes as parameter a function that takes itself two parameters (of type Int) and returns an Int. We then call this function in two different ways: passing in as parameter a function previously declared (sumNumbers) or passing in a function literal.

Last but not least, we can even define extension functions using function literals:

Combining all of these things, we can then start building nice, fluent and statically typed DSL’s

Summary

We’ve seen a brief overview of some of the functionality Kotlin provides with functions (pun not intended). There are quite a few other important features such as the ability to override operators using conventions (i.e. to override +=, define a function called plusAssign), as well as some the ability to drop braces when functions only have one arguments, inline functions, local functions etc. For more information about these and other features, check out the function section on the documentation page.