Arguments, Terribly Functional

Functions, the bread and butter of coding all around the world. We all know the obvious uses for them, such as making EVERYTHING do stuff. But I know for a fact that being first introduced to them could take quite a beating on the mind. Lets go ahead and start with some sample functions and break them down. //With swift that is

All functions start off with the keyword ‘func’ followed by the name of the function. Immediately after the name, we have parenthesis which is where we can store the arguments that the function will take. In this case, we take no arguments, have no return types and print out something my mom has said too many times maliciously.

So that’s dandy and all, but by no means amazing. So lets make this slightly more usable.

So here is something significantly more complicated than the first. We not have an argument label, two arguments of type Int and a return type of Int.

Argument labels an actually usable in the code but makes life a lot easier for the programmers who need to use the function, or to keep your sanity a few months from now. When you call on the function from now on, the argument label will be tagged on to give you a better understand of what it does if named well.

Next are the arguments themselves. In this case we have two arguments named ‘lhs’ and ‘rhs’. They are both type Int and the function will also return a Int. This function acts like a personal addition machine of sorts where we plug in two and get back an integer value that we can assign to a variable.

But you say “We know all this already!”? Well okay okay, lets move on to some cooler aspects of functions. Lets get down to business and talk about what I am truly here for.

Default parameter values! Start simple first and build up from there.

In a function such as this, we will have four arguments that might be important for the inner workings of the function. And there might even be issues where, we as programmers, might not have access to certain values at that very moment. We can go ahead and make same named functions that take in different amounts of variables.

That would be totally legal because despite having the same name, the compiler knows they are different functions due to the argument counts.

There are even more ways than just making multiple functions of same name though!

So in this variation, I am using default values on all the arguments of the function. What this means is if I DO NOT pass in a value for the argument, it will use the default, that allows me to get away with doing this…

Those are ALL valid calls of that function. I know right?! And what happened after I started playing around with this more was that realization that I could use these on class and struct initializers too. It seems that the purpose of convenience initializers were to give default values to properties that might not have values yet, so why not make it a default value instead?

I will start with this example class to talk about initializers and default values. We have 5 properties that need to be initialized and an initializer that takes in 5 arguments but they also have a default value.

Similar to what we did with the function arguments, we have complete control of the class initializers too if they are set to a default. But what would happen if we wanted to change any information inside the instanced class?

Well on snap! Because we assigned a value to those properties and they were all constants, we are unable to manipulate them any more. Looks like one drawback would be having to use variable instead of constants. Another great place to use default values could also be when you Usually have default value, but Sometimes need a specific one.

The reason I like default values Soo much is just the flexibility I have. In this example of a function I abuse, I have three arguments. I have a required argument of position, but rotation and scale has default values so I can CHOOSE whether or not I need to scale or rotate the card. Need to scale but not rotate? Done! Need to rotate but not scale? Done!

Even the Apple documentation of UIView.animate uses default values, which is why we can get away with deleting the completion Closure all together!

But don’t be fooled by the simplicity, you need to always be fully aware of what can change or be affected by these default values. In the case of my moveCard function. If my card already Has a rotation, but I default the withRotation argument, the cards rotation will reset to origin!

The list of potential applications of this is astonishingly large and although I would love to give more in-depth examples I wouldn’t want to guide anyone to poor programming practices by making everything with default values. It has its place and usefulness for sure but lets not get too carried away.

//I kind of did for something.. woops

For more information, check out the apple documentations which also covers inout and variadic arguments.

Thanks for reading and happy coding!