Computing

In Java, coders are discouraged from calling setter functions in class constructors. Even though doing so can sometimes reduce the amount of repeated code.

Consider the following class:

Unit.java

public class Unit {
	protected int health;

	public Unit(int hp) {
		// Prevents health for being set to 0 or less.
		if(hp <= 0)
			throw new IllegalArgumentException("Health must be more than 0.");
		health = hp;
	}

	public void setHealth(int hp) {
		// Prevents health for being set to 0 or less.
		// Repeat of the code in the constructor.
		if(hp <= 0)
			throw new IllegalArgumentException("Health must be more than 0.");

		health = hp;
	}

}

Instead of doing the check twice across 2 functions to ensure the incoming hp value is correct, it might occur to some coders that we can call the setter within the constructor instead, to reduce the amount of repeated code:

Unit.java

public class Unit {
	protected int health;

	public Unit(int hp) {
		// Prevents health for being set to 0 or less.
		if(hp <= 0)
			throw new IllegalArgumentException("Health must be more than 0.");
		health = hp;
		setHealth(hp);
	}

	public void setHealth(int hp) {
		// Prevents health for being set to 0 or less.
		// Repeat of the code in the constructor.
		if(hp <= 0)
			throw new IllegalArgumentException("Health must be more than 0.");

		health = hp;
	}
}

This, however, is discouraged, because (according to textbooks) setters like setHealth() can be overriden by child classes, creating unexpected or buggy behaviour in these child classes.

Continue reading →

As a programming language with its fair share of quirks, one of the many things a new Java programmer will run into is the issue of their Scanner.nextLine() calls being ignored. Consider the following Java code:

JavaNextLineProblem.java

import java.util.Scanner;
public class JavaNextLineProblem {
	public static void main(String[] args) {
		Scanner input = new Scanner(System.in);

		// Prompt the user to enter their name.
		System.out.print("Enter your name: ");
		String name = input.nextLine();

		// Prompt the user to enter their age.
		System.out.print("Enter your age: ");
		int age = input.nextInt();

		// Prompt the user to enter a description.
		System.out.print("Describe yourself in a sentence: ");
		String description = input.nextLine();

		// Prompt the user to enter a message.
		System.out.print("Enter a message: ");
		String message = input.nextLine();
	}
}

This is the desired result (user input coloured in green):

Enter your name: John
Enter your age: 21
Describe yourself in a sentence: I am awesome.
Enter a message: Hello world!

However, this is what you actually get:

Enter your name: John
Enter your age: 21
Describe yourself in a sentence: Enter a message: Hello world!

The program skips over the collection of input for the Describe yourself in a sentence prompt, and goes straight into collecting the input for the Enter a message prompt. What’s going on?

Continue reading →

If you’re using a Git-based source control, you might be familiar with the use of a .gitignore file to list files which Git is supposed to ignore when tracking files and making commits. This can be particularly useful when using Git (if you’re using GitHub Desktop, you’re also using Git) as a source control tool for projects that generate temporary or user-specific files at every run, such as Unity, as these files cannot be shared across different users of the project.

Sometimes, when setting up the repository, because of a .gitignore that is not properly set up, files that you intend to be ignored can actually get committed into the repository. If that happens, retroactively applying the .gitignore list will not help.

Continue reading →