C# for Java Developers, Part II: Methods

This is the second part of my C# for Java Developers series. Let's have a look at how to write methods in C#.

Note that this is the second and last post in this series. I’ve decided that there are a lot more interesting languages to learn than C#. The reason I’m finally publishing this second part of the guide - over two years after the first part was published - is that I’m going through my old drafts.

Please consider reading the first part before you jump into this one. All the code you see - and more - is available in the C# for Java Developers GitHub repository. A word of warning: I’m writing this guide as I learn C# myself, so don’t except everything to be 100% accurate. Consider reading this as a way to kick start your own C# adventure.

With that out of the way, let’s have a look at methods.

Methods

Like most of what we’ve looked at so far, methods in C# is pretty damn similar1 to methods in Java.

Java

package net.vegard.csharpforjavadevs.methods;

public class Methods {
    public static int area(int x, int y) {
        return x * y;
    }
}

C#

namespace VegardNet.CSharpForJavaDevelopers.Methods
{
    class Methods
    {
        public static int Area(int x, int y) {
            return x * y;
        }
    }
}
  • The structure of C# and Java methods are identical: (Optional) access modifier, (optional) implementation keywords2, return type, method name, (optional) parameter list, and a method body.
  • Both C# and Java methods can be declared abstract.
  • C# supports the virtual implementation keyword. Methods modified with this keyword can be overridden by any class that inherits it. Java has no similar keyword, because all non-final, non-private methods in Java are virtual by default, and can thus be overridden. In C#, it’s the other way around: All methods are sealed by default, and you have to use the virtual keyword to allow overriding.
  • If a method has no return type, the void keyword is used in both languages.
  • Both C# and Java use parameter pass-by-value for their basic types; C# value types and Java primitives. This means any parameter a method is working on are copies of the original. In turn, this means that modifying the value of an input parameter in the method body won’t modify the original value of the input parameter.
  • In both C# and Java, if you use reference types (i.e. an object reference) as input, however, there’s a subtle difference. If you make changes to any members of the referenced object in the method body, this will also change the value of the object’s member value. But if you change to the reference itself inside the method body - that is if you assign the reference to another instance - the original reference will not change.
  • In C# it’s possible to explicitly use “true” pass-by-reference for both value and reference types by using the ref parameter keyword. This means that any changes to an input parameter in the method body, will also change the original value of the input parameter. Java has no equivalent of the ref keyword.
  • Confused yet? You’re not alone. This is a little outside the scope of this C# and Java comparison, but it’s a concept that’s important to understand. I’ve added some examples, both for C# and Java, that try to explain how this works, in the GitHub repository. If that doesn’t help, this Stack Overflow article makes a heroic effort to explain it from a Java perspective.
  • C# also supports the out keyword, which is similar to ref except that the latter requires that the variable is initialized before it’s passed. Again, there’s no equivalent keyword in Java.
  • In Java, it’s possible to use the final keyword on parameters. If a parameter is final, it can’t be modified in the method body. Even though you’re actually working on a copy, and the original value can’t be modified, explicitly defining a parameter as final means that it can’t be modified in the method body either. This removes any confusion as to what might or might not happen to the original value if a parameter value modified in the method body. You can’t make a method parameter a constant in C# - the sealed keyword is not supported on method parameters. But you can easily argue that it’s not strictly necessary either.
  • In C#, like in Java, methods can be defined as static.
  • Both C# and Java support overriding and overloading methods.
  • Both C# and Java support variable argument lengths (varargs), but the syntax is different. In Java, the syntax is ..., as in methodName(String ... strings). In C#, you use the params keyword instead: MethodName(params string [] strings). Notice that in C#, the varargs parameter must be an array. In Java, it doesn’t, this is handled by the compiler, and the varargs parameter is accessed as an array in the method body.
  • C# Programming Guide: Methods.

Wrap up

The original plan was to cover methods, access modifiers, strings, and numbers in the second part of the guide. But it turned out that the section about methods got a lot longer than expected. Things seldom turn out the way we plan, am I right? That’s why you shouldn’t use the waterfall model, morons!

Anyway.

With the topics we’ve covered so far, you should be able to write some basic C#. Download Visual Studio, and get started.


  1. But we’ll cover expression body definitions in a later part of this series. ↩︎

  2. I have no idea what this kind of modifiers are called, so “implementation keyword” is my name for them. If you know the actual name, please let me know. ↩︎


Feedback

This post has no feedback yet.

Do you have any thoughts you want to share? A question, maybe? Or is something in this post just plainly wrong? Then please send an e-mail to vegard at vegard dot net with your input. You can also use any of the other points of contact listed on the About page.


Caution

It looks like you're using Google's Chrome browser, which records everything you do on the internet. Personally identifiable and sensitive information about you is then sold to the highest bidder, making you a part of surveillance capitalism.

The Contra Chrome comic explains why this is bad, and why you should use another browser.