The 7 Coding Styles That Are Dated

If you have been coding for more than a decade, you might have some preferred styles that you firmly believe in and stood by with your arguments to defend them till the end.

Below are some of them that I once stood by firmly once, but now I think I have to let it go.

1. Use m or this to indicate member variables

Rule: To differentiate member variables from local variables, use either one of the following

• The use of Hungarian notation i.e. mMemberVariable vs localVariable. Where m stands for member variable.
• The use of this i.e. this.memberVariable vs localVariable.

Past reason

The reason was when we read code, we can easily know if they are member variables or local variables without looking at their declaration.

class MyClass {
var mMember = "member"

    fun doSomething() {
        val local = "local"

        println(this.mMember)
        println(local)
    }
}
    

Now

If modern IDE, such text-based distinction is no longer required. See the same code below, it will automatically color them differently.

2. Explicit declare public, protected or private always

Rule: All variables and functions within a class need to be explicitly stated public, private or protected. Don’t assume the default state.

• need to explicitly state the type e.g. String or Int,
• need to explicitly state is it private or public

public class MyClass {
    public val publicVariable: String = "100"
    private fun privateFunction() {}
    public fun publicFunction() {}
}

Past reason

This is to avoid someone accessing those function or variable wrongly, i.e. if a function is not declared, the user might not be aware of the default state if it is public or private.

Now

With modern IDE, we don’t need to explicitly declare the default, e.g. for Kotlin which is public. Users will not accidentally mistake the default state as the auto-complete will only show the public methods. So not likely anyone will confuse what’s is the default state.

If there’s any wrong usage (e.g. access private function), it doesn’t error out only at compile time. It errors out immediately with a clear message.

3. Explicit declare a variable type always

Rule: All variables should be declared with its type even if it is clear from the value it has been assigned e.g. need to explicitly state the type e.g. String or Int

public class MyClass {
    public val publicVariable: String = "100"
    private fun privateFunction() {}
    public fun publicFunction() {}
}

Past reason

This is to avoid someone accessing those functions or variables wrongly, e.g. a variable got assigned to the wrong type, and cause a compile error.

Now

If modern programming languages, there is no need to explicitly state the type of a variable if it is inferable and unambiguous. This is called type-inference . It is available in many modern languages today.

If there’s any wrong assignment etc, it doesn’t error out only at compile time. It errors out immediately with a clear message.

4. Member variable should always be private

Rule: All member variables that should be private and accessed through getter and setter, applies to member variables that need to be set or get externally.

public class MyClass{
    private var member = "member";

    public fun getMember(): String {
        return member;
    }

    public fun setMember(value: String) {
        member = value;
    }
}

Past reason

If we make it public for setting and getting, in the event we need to perform some action when they are set or get, we need to change all the code that accesses it.

So if we limit to getter and setter, we are in control of it e.g.

class MyClass{
    private var member = "member";

    fun getMember(): String {
        println("Setting member")
        return member;
    }

    fun setMember(value: String) {
        println("Setting member with $value")
        member = value;
    }
}

Now

In modern languages (e.g. Kotlin), we can easily insert the variable getter or setter on the variable when needed without explicitly having two different functions just to set and get.

So we can code as below without having additional setter and getter function to the class.

class MyClass {
    var member = "member"
}

When we need to do something to the setter or getter, we can easily add them without needing to change the code that accesses member.

class MyClass {
    var member = "member"
        get(): String {
            println("Setting member")
            return field
        }
        set(value: String) {
            println("Setting member with $value")
            field = value
        }
}

5. Start and end curly brackets should be aligned

Rule: All curly brackets should be aligned at the same column so that we can find their pair easily e.g.

class MyClass 
{
    private var member: String = "member"
    
    fun doSomething(state: Boolean)
    {
        val local = "local"        println(member)
        println(local)
    }
}

Past reason

The reason was by looking vertically we can easily find their pair, hence know where the scope of the function is.

Now

With new IDEs, as long as the code looks neat, we no longer need to align the start and end curly bracket on the same column.

class MyClass {
    private var member: String = "member"
    
    fun doSomething(state: Boolean) {
        val local = "local"        println(member)
        println(local)
    }
}

This is because we can collapse or expand them easily as shown below.

6. Use tab for all indentation

Rule: use tab for all indentation instead of using space

Past reason

This reduces the number of typing required. e.g. the below shows when using space, one has to type many times

Now

With IDEs, it will auto-indent for us with an appropriate number of spaces. And having spaces will also ensure all code looks consistent across users environments.

7. Use of semicolon to end a code statement

Rule: When ending a code statement, a semicolon is required.

Past reason

This is required since the olden days programming language even C and C++, Java, etc, for the parser to recognize it has ended. Partially because we have 80 columns, and hence when need to code more for a statement, we can code in several lines for a statement.

Now

With new modern language (e.g. Kotlin), the need to code a long statement is no longer the tren (e.g. we can name variable shorter, reduced indentations).

Even if we need to code longer statements we are no longer constrained by 8 columns (though not a good practice). Besides, our monitor these days are longer

So if a language allows no semicolon, go for it!

By changing my belief of the 7coding styles above, I have changed my code as below

The world is ever-changing. What’s required in the past might not be relevant anymore. With technology and tools, we should always re-evaluate the rules we once had, and progress on.

Feel so much younger. Check out how the coding profession has changed!

Originally published in Elye