DEV Community: Mark Rubin

Where should main live

Mark Rubin — Thu, 01 Sep 2022 04:01:46 +0000

This is part of a brief series on Good Habits For Java Programmers.

A Java program needs to have a method with the signature
public static void main(String args[]) in some class. It serves as the entry point for your program. When you run your program, the Java runtime finds this magic entry point, calls it, and you're off to the races. You'll have to house this method in a class, because that's just how it works. The question entertained by this post is in which class should the main method go.

In How To Get Out Of Main And Reduce Static, we moved most of our logic out of our public void static main method into our Square class and ended up with this code:

public class Square {
    private float sideLength = 0.0f;

    public static void main(String args[]) {
        Square square = new Square();
        square.setSideLength(3.2f);
        System.out.println("The area of the square is " + square.getArea());
        System.out.println("The perimiter of the square is " + square.getPerimeter());
    }

    public void setSideLength(float length) {
        sideLength = length;
    }

    public float getArea() {
        return sideLength * sideLength;
    }

    public float getPerimeter() {
        return 4 * sideLength;
    }
}

It's a good idea to review that post. In it, I noted that we should think of main as just a contractual rendezvous point with the Java runtime. It's how the Java runtime finds a place to start your program, and that is its primary role. Given that, does main belong in Square? It really doesn't have anything to do with a square, the shape. If I ask you to tell me the properties of a square that you should model with a Square class, you'll tell me about side length and the formulas for the area and perimeter of a square and the like (maybe what the angle measurements are for a square, etc.), but you wouldn't say that they have a contractual entry point through which a Java runtime can start a Java program.

So with that in mind, it should seem off that main is a method of Square. It can be convenient to put it there: in this, case it keeps your program all in one file. But conceptually, it's odd.

I'll pile on here. What if you enhance your program to hardcode values for other shapes (e.g. circle, triangle) and output their areas and perimeters? Would you insist on keeping your main in Square? Why Square and not Circle?

Here's a similar point. Let's say you were a reader of the enhanced program and not its author: would you know which file/class had the magic main method in it from class names such as Square, Circle, Triangle? Would you say to yourself "Oh, it has to be in Square. Why would it be anywhere else?". Once programs start to get a bit large -- even just a few files -- I find myself having to hunt for students' main implementations.

So I recommend having a Main class (or some class with "Main" in the name) whose sole purpose is to house the public static main method. Make a Main class and put your public static void main in there. Now it'll be obvious to you and to everyone where your main method lives. And however your program grows over time, you won't have to move it from one class to another to accommodate the growth. I need to note that this is not universal convention, although I bet not many would dislike it much: it can never really hurt, and it can help.

That also aligns nicely with the idea that main is just a contractual entry point. Classes should model something, and if you follow this advice, your Main class is then modeling that it's the entry point for your program. It advertises no more than that, but it does advertise that its purpose is to house main (unlike Square's name). So in our example, we'd have:

// In Main.java
public class Main {
    public static void main(String args[]) {
        Square square = new Square();
        square.setSideLength(3.2f);
        System.out.println("The area of the square is " + square.getArea());
        System.out.println("The perimiter of the square is " + square.getPerimeter());
    }
}

// In Square.java
public class Square {
    private float sideLength = 0.0f;

    public void setSideLength(float length) {
        sideLength = length;
    }

    public float getArea() {
        return sideLength * sideLength;
    }

    public float getPerimeter() {
        return 4 * sideLength;
    }
}

Does main still contain too much?

I'm going to get more controversial here. I think even this version has main doing too much. I'd prefer that Main call a method on another class that's well named for doing the work here for creating our Square. I'd like main to have as little logic as possible: it's there to fulfill our contract with Java and nothing else. Anything else that we do that's interesting should be done in a class whose purpose is to do that thing. I'm advocating keeping this contract with Java separate from everything else. I'm pretty extreme here. I'd rather see something like

// In Main.java
public class Main {
    public static void main(String args[]) {
        Driver.startTheProgram();
    }
}

// In Driver.java
public class Driver {
    public static void startTheProgram() {
        Square square = new Square();
        square.setSideLength(3.2f);
        System.out.println("The area of the square is " + square.getArea());
        System.out.println("The perimiter of the square is " + square.getPerimeter());
    }
}

// In Square.java
public class Square {
    private float sideLength = 0.0f;

    public void setSideLength(float length) {
        sideLength = length;
    }

    public float getArea() {
        return sideLength * sideLength;
    }

    public float getPerimeter() {
        return 4 * sideLength;
    }
}

Now Main does nothing than fulfill our contract with the Java runtime, Driver is in charge of our logic for how to drive our program, and Square simply models a Square. If we want our program to do more, we put more in Driver. If we change our mind about what to do first, we either change Driver's startTheProgram implementation or we create another class that we call from main to do something first, and have it call Driver, etc.

I have to admit this: you'll find lots of folks using Main classes or appreciating my point about having a separate Main class; you'll probably find fewer excited about my creating yet another class, such as Driver that main calls, especially for small programs.

Naming Conventions

Mark Rubin — Wed, 31 Aug 2022 18:50:45 +0000

This is part of a brief series on Good Habits For Java Programmers.

Java allows you a lot of flexibility in how you name classes, variables, methods, etc. But there are conventions that Java programmers follow. Obeying these conventions is important: it makes it much easier for all of us to comprehend each others' programs quickly and easily.

Class and Interface names begin with an uppercase letter

Your class and interface names should always begin with an uppercase letter. Java does not require this -- you won't get a syntax or compiler error if you start your class name with a lowercase letter. But it's just how things are done. Not following this convention will ultimately lead to confusion.

Variable, method, parameter names should always begin with a lowercase letter

Again, this is not required by Java, and your Java programs will compile and run if you break this convention. Nonetheless, convention has value.

Use CamelCase for class, variable, parameter, and method names

Examples:
double sellerCost;
double buyerPrice;
double getProfit(double sellerCost, double buyerPrice)
void displayDataAsTable()
class ProfitCalculator

Meaningful names for your classes, variables, methods, and parameters are generally multiple words stuck together in sequence to make a small phrase that describes what they do or what they're for. You should be able to get the idea from the examples above.

If it's a class or interface name, you start with an uppercase letter; if it's a variable, method, or parameter name you start with a lowercase letter. Then you lowercase the rest of the letters in the first of the jammed together words, and then capitalize the first letter of the next word, lowercase its remaining letters, capitalize the first letter of the next word, and so on. The examples are easier to understand than the explanation.

There are other rules

These cover most everything you'll use early on.

There are rules for so-called constants in Java, which use a capitalized SNAKE_CASE: e.g.

public static final double MAX_PRICE = 100.0;

and more constructs. I only mention this for completeness. Don't sweat them. Focus on the rules for class names, variables, methods, and parameters, and you'll be in great shape.

Writing Good Comments

Mark Rubin — Wed, 31 Aug 2022 18:50:42 +0000

This is part of a brief series on Good Habits For Java Programmers.

Don't narrate your code

Many beginning Java programmers have been taught to make sure to include comments in their programs. And because they are good, dutiful students, they do. A great deal of this time, those comments are simply narrations of their code, and so are unnecessary. Here are some examples in an abbreviated class:

/** Calculates profit. */
public class ProfitCalculator {
    private double buyerPrice; // the buyer's price
    private double sellerCost; // the seller's cost

    // default constructor
    public ProfitCalculator() {
        // assign buyerPrice
        this.buyerPrice = 0.0;

        // assign sellerCost
        this.sellerCost = 0.0;
    }

    public ProfitCalculator(double buyerPrice, double sellerCost) {
        // Save the buyer price in a member field.
        this.buyerPrice = buyerPrice;

        // Save the seller cost in a member field.
        this.sellerCost = sellerCost;
    }

    // Sets the buyer price.
    public void setBuyerPrice(double buyerPrice) {
        this.buyerPrice = buyerPrice;
    }

    // More code would follow.
}

None of these comments add anything useful.

Because the author has used meaningful names for the variables and methods, the comment here
private double buyerPrice; // the buyer's price
doesn't add anything and isn't needed.

A method with the signature
public void setBuyerPrice(double buyerPrice)
had better set the buyer price! So a comment telling us that isn't needed, or else the author ought to rename their method and their parameter!

Let's look at this one:

    // Default constructor
    public ProfitCalculator() {

This is interesting because texts that are teaching students what a default constructor is will often have a comment just like that on their examples of default constructors. That's helpful to you as a student. And so it's totally natural that you would mimic the example from your texts. But the programs you're mimicking are intended to teach you what a default constructor is; the programs you're writing are not meant to be examples to teach others how to code, and so you shouldn't include comments as if they were. Which means not mimicking your examples in this way.

This leads to a bit of a tricky situation for students. Maybe you think it's still useful to add to your default constructor // default constructor because it's helpful to you as you're starting out. I'm torn here: I like that you're adding comments that you think are genuinely helpful and are genuinely helpful to you. But we can assume that the readers of our code know basic Java, and so don't need default constructors and other standard bits of Java highlighted for them unless for some reason, it would be tricky to see those things without your comment.

Another example

    // default constructor
    public ProfitCalculator() {
        // assign buyerPrice
        this.buyerPrice = 0.0;

        // assign sellerCost
        this.sellerCost = 0.0;
    }

Anyone familiar with Java will know that those lines in the body of the constructor are assignment statements and what variables the assignments are being made to. So it's not helpful to add those comments.

So what comments should I include?

I'm going to be pretty heretical here. If you have used meaningful names for your classes, variables, methods, parameters, and so on, maybe very few! Ideally, the code is self-documenting because it's obvious from the names of things and the flow of your statements what the program is doing and why. Especially for the size of the programs you're writing.

Less heretically, any time your program does anything important that a reader might not pick up on right away, that deserves a comment. What's wrong with the comments in the previous section is that they focus too much on what the code does rather than on why it does it. The what is often not a problem for fluent Java readers. It's when they may not understand why your code does what it does that they may need help.

So if you, for example, skip a line of input from a file or an element of an array for some reason, you should comment that:

        // We need to skip printing the first price because
        // it has already been printed in <some other place>, 
        // so we start iterating at 1.
        for (int i = 1; i < prices.length; ++i) {
            System.out.println(prices[i]);
        }

And it's good advice to have a top-level comment on your program saying what the program does in general and any interesting facts about it. And it's generally good advice to think about putting a top-level comment on your classes, describing what the classes do and how they work, although the same principles apply here, too, about making sure you're adding something meaningful in your comment: if it's totally obvious what a ProfitCalculator class does, perhaps a comment isn't necessary.

So some fellow instructors may dislike this advice because instructors are generally pleading with their students to add comments. I also plead with you to add comments, but when they are necessary and meaningful. I'm pleading with you not to add comments that add no real value. And I'll plead with you even harder to use meaningful names.

Grammar

Comments should be grammatical

Comments are there to help you and especially your readers. If they are ungrammatical, they add a mental tax to you and your readers; poor grammar makes it harder to figure out what was meant. Not everyone is good at grammar, and that's okay. Do your best, but do try.

Comments should not contain abbreviations

This is a bit of a hot take, but don't abbreviate where elaboration would be clearer, except when using very standardly abbreviated terms, such as e.g. and etc.. So rather than say
// Calc the profit.
say
// Calculate the profit.

Comments should be complete sentences that end with periods.

This is absolutely a hot take, and definitely most developers don't do this. I learned to push for this from a peer, and I love it. Again, comments are meant to be helpful. Complete sentences are generally more helpful than not. And deciding on writing a complete sentence (and removing abbreviations) eliminates the question for you of how non-standard your English is allowed to be. Just write a complete, grammatical sentence with full words, and you and your code readers will be grateful when reading them, and you won't have to debate in your head if your sentence fragment with abbreviations is understandable. It makes programming easier for you to write your comments well and consistently because now you have a simple rule.

== true and == false are Redundant

Mark Rubin — Wed, 31 Aug 2022 18:50:38 +0000

This is part of a brief series on Good Habits For Java Programmers.

Consider this:

        if (isValid == true) {
            System.out.println("The input is valid.");
        }

This won't do anything differently from this variant:

        if (isValid) {
            System.out.println("The input is valid.");
        }

Similarly,

        if (isValid == true && isNew == true) {
            System.out.println("The input is valid and new.");
        }

won't do anything differently from

        if (isValid && isNew) {
            System.out.println("The input is valid and new.");
        }

Use the versions that don't tack on the == true. That's what Java programmers do, conventionally, and the shorter expressions are simpler to read. Well, they're simpler to read once you get the hang of things. Admittedly, you might find it easier to insert a secret "equals true" when reading these boolean expressions to yourself. I did when I was starting out. But, conventionally, we don't write our boolean expressions that way.

Similarly, for false checks, we don't, conventionally, write

        if (isValid == false && isNew == false) {
            System.out.println("The input is not valid and not new.");
        }

We write

        if (!isValid && !isNew) {
            System.out.println("The input is not valid and not new.");
        }

Out loud, professionally, we read this as "if not isValid and not isNew then..." But if you need to mentally adjust that to "if isValid is false and isNew is false then..." that's perfectly fine. Lots of folks do. But the Java is written using the not operator, !.

Always Use Braces For if/else

Mark Rubin — Wed, 31 Aug 2022 18:50:36 +0000

This is part of a brief series on Good Habits For Java Programmers.

Yes, it's true, you don't need curly braces to introduce a scope for a bit of Java such as

        if (isValid)
            System.out.println("The input is valid.");

or even for

        if (isValid)
            System.out.println("The input is valid.");
        else
            System.out.println("The input is not valid.");

But it's dangerous and introduces style inconsistencies not to.

The danger

The danger comes from the fact that it's far too easy to add a second thing to do when those if or else conditions are met and not realize you need to now add the curly braces to make sure both things are done when the condition is met. Consider

        if (isValid)
            System.out.println("The input is valid.");
            System.out.println("It sure is."); // This will always execute, even if isValid is false.

Oops. That second line will always execute, regardless of the whether isValid is true or false. The author probably wanted to add curly braces:

        if (isValid) {
            System.out.println("The input is valid.");
            System.out.println("It sure is."); // This will only execute if isValid is true.
        }

Similarly for

        if (isValid)
            System.out.println("The input is valid.");
        else
            System.out.println("The input is not valid.");
            System.out.println("It sure isn't."); // This will always execute, even if isValid is true.

The author probably wanted to add curly braces:

        if (isValid) {
            System.out.println("The input is valid.");
        } else {
            System.out.println("The input is not valid.");
            System.out.println("It sure isn't."); // This will only execute if isValid is false.
        }

Style consistency

A lot of our ability to read programs easily comes from the authors' obeying conventions and their being consistent in their coding style.

For example, if a file is formatted inconsistently with different indentation patterns everywhere, it's hard to take in. You wouldn't want to read this:

// Don't do this!
        if (isValid) {
     System.out.println("The input is valid");
        } else {
            System.out.println("The input is not valid");
                System.out.println("It sure isn't"); 
        }

Sometimes adding curly braces for if statements and sometimes not introduces inconsistency. Always using braces introduces consistency, and consistency increases readability and maintainability. The less work we have to do when understanding a program, the better.

Default To private Access Modifiers

Mark Rubin — Wed, 31 Aug 2022 18:50:29 +0000

This is part of a brief series on Good Habits For Java Programmers.

Access modifiers really do matter. It's hard to appreciate that with the small programs you're writing all by yourself when you first learn to program. But as programs get bigger and as more people work on them over time and together, the access modifiers matter more and more.

Why is a large topic, and it may be hard to appreciate with the programs you've been writing. So I'll just be brief about one of the main reasons. So much of the trouble of hunting down bugs in our code is caused by its not being obvious when and why a variable changes state during the execution of the program or when and why a method is called during that execution. And even when it's obvious, there may be so many potential places that variable or method are accessed, we can't keep track of them all in our heads easily to help us think through the potential problems, especially over time and the larger the codebase gets. So one of the ways we combat this is by restricting access to those variables and methods. It reduces the surface area of what could possibly go wrong and what we have to think about when hunting down a bug: "Since this variable is private, it can only be modified by methods in this class, so I can restrict myself to thinking about only what this class does to find my bug." It also restricts the possibility of our making errors: you can't mistakenly call a method on a class from another class if it's not accessible to that second class.

But I fear this may be one of those nuisance topics where your instructors always hassle you to update your access specifiers to be more restrictive and take off points when you don't, and it seems pointless to you. It might be one of those things where you'll just have to develop the habit of doing it the "right" way, according to your instructors, just to get them to stop bothering you and to give you higher grades before you come to experience why this is so valuable a practice.

So default to specifying modifiers on methods as private. That's the habit you want to develop. Make them public only if you need to.

And always make member variables private. If you need to somehow expose the ability to set or get their values, create methods that provide a way for a user of your class to set or get the value from the method. Okay, there are exceptions, but none we need to talk about here, except if you're making a constant: e.g. public static final double MAX_SALARY = 100.0;.

How To Get Out Of Main And Reduce Static

Mark Rubin — Wed, 31 Aug 2022 18:50:26 +0000

This is part of a brief series on Good Habits For Java Programmers.

In the beginning...

When you write your first program in Java, you encounter the need to have a method with the signature

public static void main(String args[])

that serves as the entry point for your program. When you run your program, somehow the Java runtime finds this magic entry point, calls into, and you're off to the races. You'll have to house this method in a class, because that's just how it works.

Then, whatever you learn next, you'll probably be reading and writing short programs that exercise the new Java language bits inside that public static void main method. Maybe you're learning how to iterate with a for loop, and so read or write a little program to sum up all the evens between 0 and 10.

public static void main(String args[]) {
    int sumOfEvens = 0;
    for (int even = 0; even <= 10; even += 2) {
        sumOfEvens += even;
    }
    System.out.println("The sum of evens from 0 to 10 is " + sumOfEvens);
}

It makes sense to keep that code in main from a teaching and learning standpoint: it's the simplest place to put the code, and by introducing no additional complexity, the instructor and you get to focus on the other concepts being taught -- say, how a for loop works or how to use a local variable (sumOfEvens) or how the algorithm works (adding 2 each time takes us to the next even). I have no problem with this teaching methodology. In fact, I think it's a good idea to leave you to code in main while you focus on other things.

main is simply an entry point. It is not for modeling your data or problem space.

But let's move forward some number of weeks in your learning. You're starting to learn how to use classes to model a domain, and your assignment is to create a program that asks you to hardcode the length of the side of a square, and print out the area and the perimeter. So you create something like this:

public class Square {
    public static void main(String args[]) {
        float sideLength = 4.0;
        System.out.println("The area of the square is " + sideLength * sideLength);
        System.out.println("The perimiter of the square is " + 4 * sideLength);
    }
}

This is a good start. It does what's asked. And it's somewhat nice that the class is named Square. The name of the class tells me that we're doing something related to a Square in this class, but we're not really doing much modeling of a Square here. There's no representation of a side's length in the Square class and there are no methods that we'd expect on a Square class. We call the class Square, but since all of the logic for the squarey things we do live in main, there actually isn't much that's squarey about this class, other than that the magic Java program entry point, main, is packed with a series steps that relate to doing some operations on a square.

Let's dwell on this. The main method is not the best place to put your algorithms or to model the problem domain you're modeling: the need for a main comes from a contract between the Java runtime and you about how to start your program. That's it. It's how the Java runtime finds a place to start your program, and that is its primary role. It's not for modeling your problem space or writing interesting algorithms: that modeling and those interesting algorithms belong in the distinctive methods and and fields of your classes. Treat main solely as an entry point for the Java runtime to find, and put interesting work into your class methods.

Don't get stuck in the `static` trap

So you learn about class methods and class fields, and you rewrite your Square class:

public class Square {
    private static float sideLength = 0.0f;

    public static void main(String args[]) {
        setSideLength(3.2f);
        System.out.println("The area of the square is " + getArea());
        System.out.println("The perimiter of the square is " + getPerimeter());
    }

    public static void setSideLength(float length) {
        sideLength = length;
    }

    public static float getArea() {
        return sideLength * sideLength;
    }

    public static float getPerimeter() {
        return 4 * sideLength;
    }
}

This is an improvement. I can see more why this class is named Square: it stores a side length, and it has methods to calculate the area and perimeter of a square, using the correct algorithms for them based on a square's side's length.

But there's something funny here. Why is everything static? The field sideLength is static, and so are getArea and getPerimeter? In my experience, this is not so much a conscious choice, but a carry over from the fact that main is static. main has to be static because that's the contract with the Java runtime. And students get stuck then figuring out how to not carry on that static. They find that they can't call directly a method named setSideLength from their static main unless setSideLength is static, too. And then a static setSideLength can't set a value on that field sideLength unless it's static.

So there are two big issues here. The first is whether we want all these to be static. We don't, and I'll explain why. But more than that, the bigger conceptual issue is that it's not that students have made a choice I disagree with to make the field and the methods of Square static: it's that students feel that they are forced into it by their static main.

There's a big difference between static fields and non-static (instance or member) fields and a big difference between static methods and non-static (instance or member) methods. The difference I want to focus on for now is that a static field is shared among all instances of Squares, where each instance of Square has its own private copy of non-static fields. Conceptually, do we want to make it so that all Squares have the side length 3.2 when I set that value, or that just a particular Square has a side length of 3.2? Or put more broadly, do we want the Square class to model squares as if they all share the same side length, or do we want to allow it to model that different squares have different side lengths? The second, for sure. In that case, we don't want sideLength to be static.

Okay, so we don't want that field to be static, but as I said, most students don't choose to make it static: they feel forced into it because of the call to setSideLength in their public void static main, which itself is seemingly forced into being static

The solution is to create an instance of Square, and call a method on that:

public class Square {
    private float sideLength = 0.0f;

    public static void main(String args[]) {
        Square square = new Square();
        square.setSideLength(3.2f);
        System.out.println("The area of the square is " + square.getArea());
        System.out.println("The perimiter of the square is " + square.getPerimeter());
    }

    public void setSideLength(float length) {
        sideLength = length;
    }

    public float getArea() {
        return sideLength * sideLength;
    }

    public float getPerimeter() {
        return 4 * sideLength;
    }
}

Much better! We now have made sideLength a non-static, instance field, and we access it through non-static, instance members. We should probably add a constructor to Square that takes an argument for the side length, too, but let's leave it at this.

Summary

There are two lessons here I want to summarize:

It's very easy to feel stuck having to make everything in a class static because you start calls to it from a static method, public static void main. But you don't have to be stuck: within your main, you can create an instance of your class and then make instance method calls on that instance. Those instance methods can access instance fields. If you want to make a field or method on your class static because that's appropriate, too, then great! But you don't have to.
public static void main serves as a rendezvous point between the Java runtime and your program. It is a contract between you and Java about how to start your program. That's it. It's not the place to put parts of your modeling or algorithms specific to your classes and their desired behaviors.

Here's a related post about where main should live.

What's A Good Error Message

Mark Rubin — Wed, 31 Aug 2022 18:50:23 +0000

This is part of a brief series on Good Habits For Java Programmers.

As you progress in your programs, you'll start to handle error conditions. Maybe you'll prompt your users to input a value for the side of a square, and they type a negative value or a string. There's the whole programming side of how you detect those error conditions, but that's not what this post is about. This post is about how to surface those errors.

Error messages should be specific and actionable

Let's say you have a UI where you ask your user to enter in a date of birth and a name. The user can enter in an invalid value for any of those. Tell them specifically what they did wrong and suggest what they can do to fix it. If they've made multiple errors, tell them about the multiple errors.

Let's say you require that the name not be empty and you expect your dates to be entered in the format MM/dd/yyyy (two digit month followed by a slash, followed by a two digit day followed by a slash, followed by a four digit year). The user enters in some data, and they use an improper date format: they enter "5/14/70". An error message saying "Something went wrong" or "Invalid input" is not helpful. What went wrong? What should they fix? Should they fix their name or their date? And what's wrong with their name or their date? Tell them their date is in an incorrect format and what format you expect. It's frustrating as a user to have no idea how to fix whatever seems to be broken with the data they entered.

Tell them about all their errors at once, if you can

Let's say they enter an incorrectly formatted date and left the name field blank. Tell them about both errors. It's frustrating for a user to fix one error and then resubmit their data and be told there are more errors.

Don't use computer jargon in your error messages

When you're learning to program, you don't really have users: usually, there's you, the programmer pretending to be a user, and your instructor. And both of you are well versed in computer jargon. But you're practicing writing programs for other people. And other people are usually not Java programmers. So don't say something like "Price is incorrectly entered. Please enter a float." as your error message. Don't expect your user to know what a float is.

Error messages should be grammatical, and usually should be complete sentences

Anything else puts a burden on your user to interpret what you must have meant. Grammatical, clear, full sentences are preferred because when you use them, your users will have the best chance of understanding what went wrong and how to fix it.

Double check your error messages

I see a lot of mistakes from beginning programmers that come from copy and pasting. They copy an error message about expecting an integer input to the place where they let a user know about an error where a string is expected, and so they tell the user that an integer is expected when really it's a string that's expected. We all do this - not just beginning programmers. But it's something we should all be reviewing to try to catch on our own.

How To Order Your Fields And Methods

Mark Rubin — Wed, 31 Aug 2022 18:50:20 +0000

This is part of a brief series on Good Habits For Java Programmers.

Be conventional

Java does not require that you declare your fields at the top of the class and your methods below that. But that's what we do conventionally. Java does not require that constructors are placed above other methods, but that's what we do. I think both of those habits promote readability on their own -- that it's generally easier to comprehend a class that way. But I'm not sure because that way of presenting a class is extremely conventional -- it's what everyone in the industry does. So I can't tell if these placements inherently make a class more readable, or they make a class more readable because I'm used to seeing a class presented that way and so can find my way around the class more easily when people obey the convention. Convention and patterns are very powerful tools for promoting understanding.

You should be conventional, too, and follow those rules.

The rest of what I'm going to say is definitely not universally practiced convention. In fact, for much of my career, I didn't follow these rules. When I joined Block (nee Square), I was taught these rules, and I found them extremely helpful. So I'm passing them on to you.

Put public things before private things

I know, I know, we instructors are such nuisances when it comes to access modifiers, always telling you when you left something public that should be private. We harp on it so. It's annoying. But it is important.

If you follow the rules in this post, you probably don't have public member fields, but there can be reasons to make exceptions as you progress. Put all the public fields above the private fields.

You almost certainly will have public and private methods though. Same rule: put the public ones above the private ones.

Why? It goes back to why we even make the distinction between public and private access modifiers. Our publicly modified bits of code are available to any class to access. They represent the public face of your class: it's what is advertised to the rest of your classes what they can do with your class. So programmers trying to use your class will want to know what they can do about it, and putting that information at the top of the class is helpful.

On the flip side, the programmers who use your class don't really care how it's implemented, so they don't care to or need to read or pay attention to your private helper methods. Those are there for your class to do as it advertises it does, but people who use your class don't care and shouldn't care about those details.

This may all be too abstract and you may not have had enough experience working on a shared project or a large project to appreciate this. In that case, I'm sorry to say you should just treat this as advice that some day will make more sense to you if you continue to program. At the least, it's a rule, and it provides a convention you can be consistent with, and that has value.

If possible, calling methods go on top of called methods

If you have a method private Date getDate() and it uses a helper method private boolean isValidDate(Date date), all things being equal, put getDate above isValidDate. That way, when you or anyone else is reading your code, they can follow the bigger picture before diving into the details. They will read that getDate relies on isValidDate and set that aside. Later, they can figure out what isValidDate does.

Here's another way to think of it. In English, we read from the top of the page down. And in general, when reading, we expect to encounter the more important things before the less important things. So we expect meatier, more algorithmically relevant methods to come first, and their helpers to come later.

Sometimes you can't always obey this: you have methods crisscrossing in how they all call each other. That's okay. Just do your best. Exercise judgment over which should come before the other, focusing on what makes it easier for someone reading your class to figure out how it works.

Violate these rules if it makes sense

Readability, discoverability, and maintainability are the real goals here. If it seems to you that they are better met by a different ordering, go for it. As long as you're motivated by making your class easier to use or to understand or to maintain, you're focusing on the right things.

Where does main go?

What about public static void main(String args[])? If that's in your class, where should it go?

This is sort of a trick question. It probably shouldn't be in your class at all. But if it is there, I recommend it be either the first thing we see, above your fields, or just after your fields. I do have one friend who says he would be surprised to see it anywhere except at the bottom of a class, though. Wherever it gets put, it's incredibly important that it can be spotted easily and quickly, and not buried away in the middle of your class.

But as I said, you know what makes it even easier to spot and less hard to find a place for in your class? Not having it in your class to begin with. Okay, it has to be in some class. How about in a class named Main, dedicated to housing main?

Method Decomposition And Class Decomposition

Mark Rubin — Wed, 31 Aug 2022 18:50:16 +0000

This is part of a brief series on Good Habits For Java Programmers.

In the beginning...

When you're first learning Java, most of the time you'll be writing short programs whose code is placed entirely in a public static void main method of a class that does nothing but host that main method. For example, maybe you're learning how to iterate with a for loop, and so read or write a little program to sum up all the evens between 0 and 10.

public static void main(String args[]) {
    int sumOfEvens = 0;
    for (int even = 0; even <= 10; even += 2) {
        sumOfEvens += even;
    }
    System.out.println("The sum of evens from 0 to 10 is " + sumOfEvens);
}

It makes sense to keep all of that code in main from a teaching and learning standpoint: it's the simplest place to put the code, and by introducing no additional complexity, the instructor and you get to focus on the other concepts being taught -- say, how a for loop works or how to use a local variable (sumOfEvens) or how the algorithm works (adding 2 each time takes us to the next even). I have no problem with this teaching methodology. In fact, I think it's a good idea to leave you to code in main while you focus on other things.

This was a small program, but since this is how students start, and each incremental addition in size feels so, well, incremental, often students stay with this model, eventually writing programs with far more code in their public static void main method than is advisable. As soon as students learn what methods are and how to call them from one another, they should start decomposing their logic from main into submethods: main will call one or more helper methods which themselves may call one or more helper methods, and so on, until each method is simple and does a single thing. The goal is to have well named methods where each method has a single responsibility that aligns with the name of the method.

Converting a single method that has lots of code embedded in it to do several things into multiple methods is called "decomposition" because it involves breaking apart (decomposing) the single big method into several smaller methods.

Decomposing even this small example

Some students appreciate the point, but aren't sure how to apply it, especially for a small example like this. What would decomposing this look like? Here's one go at it:

    public static void main(String args[]) {
        int sumOfEvens = sumEvensUntil(10);
        outputSumOfEvens(sumOfEvens);
    }

    private static int sumEvensUntil(int until) {
        int sumOfEvens = 0;
        for (int even = 0; even <= 10; even += 2) {
            sumOfEvens += even;
        }
        return sumOfEvens;
    }

    private static void outputSumOfEvens(int sum) {
        System.out.println("The sum of evens from 0 to 10 is " + sum);
    }

Imagine that instead of hardcoding that 10 for our stopping point, we prompt the user for our stopping point. Then we might have:

    public static void main(String args[]) {
        int stoppingPoint = requestStoppingPoint();
        int sumOfEvens = sumEvensUntil(stoppingPoint);
        outputSumOfEvens(sumOfEvens, stoppingPoint);
    }

    private static int requestStoppingPoint() {
        System.out.println("Type in a non-negative integer for the stopping point.");
        Scanner scanner = new Scanner(System.in);
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        return scanner.nextInt();
    }

    private static int sumEvensUntil(int until) {
        int sumOfEvens = 0;
        for (int even = 0; even <= 10; even += 2) {
            sumOfEvens += even;
        }
        return sumOfEvens;
    }

    private static void outputSumOfEvens(int sum, int stoppingPoint) {
        System.out.println("The sum of evens from 0 to " + stoppingPoint + " is " + sum);
    }

Maybe we request a starting point, too:

    public static void main(String args[]) {
        int startingPoint = requestStartingPoint();
        int stoppingPoint = requestStoppingPoint();
        int sumOfEvens = sumEvensUntil(startingPoint, stoppingPoint);
        outputSumOfEvens(sumOfEvens, startingPoint, stoppingPoint);
    }

    private static int requestStartingPoint() {
        System.out.println("Type in a non-negative integer for the starting point.");
        Scanner scanner = new Scanner(System.in);
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        return scanner.nextInt();
    }

    private static int requestStoppingPoint() {
        System.out.println("Type in a non-negative integer for the stopping point.");
        Scanner scanner = new Scanner(System.in);
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        return scanner.nextInt();
    }

    private static int sumEvensUntil(int start, int until) {
        int sumOfEvens = 0;
        for (int even = start; even <= 10; even += 2) {
            sumOfEvens += even;
        }
        return sumOfEvens;
    }

    private static void outputSumOfEvens(int sum, int startingPoint, int stoppingPoint) {
        System.out.println("The sum of evens from " + startingPoint + " to " + stoppingPoint + " is " + sum);
    }

Let's appreciate the difference here from what a typical beginner's program would look like to do the same.

    public static void main(String args[]) {
        System.out.println("Type in a non-negative integer for the starting point.");
        Scanner scanner = new Scanner(System.in);
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        int startingPoint = scanner.nextInt();

        System.out.println("Type in a non-negative integer for the stopping point.");
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        int stoppingPoint = scanner.nextInt();

        int sumOfEvens = 0;
        for (int even = startingPoint; even <= stoppingPoint; even += 2) {
            sumOfEvens += even;
        }

        System.out.println("The sum of evens from " + startingPoint + " to " + stoppingPoint + " is " + sum);
    }

I hope you can see that the second, non-decomposed version, is harder to read and to follow, even for such a short program. Why is that? In large part it's because the entire logic of the program is presented in a single, long, linear sequence of code. You have to mentally figure out what each set of lines does, assign a sort of mental label to what each does, then consider how each interacts with the next mentally labeled bit of code, and so on, down the line. Beginning Java programmers acknowledge this by putting in those newlines to help separate out those mentally labeled bits of code. There's a reason why the newlines are placed where they are: their placement is an attempt to introduce structure and order onto what otherwise seems unstructured and unordered. In fact, you'll often see new programmers add comments to help them and their readers keep track of what's going on:

    public static void main(String args[]) {
        // Get the starting point.
        System.out.println("Type in a non-negative integer for the starting point.");
        Scanner scanner = new Scanner(System.in);
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        int startingPoint = scanner.nextInt();

        // Get the ending point.
        System.out.println("Type in a non-negative integer for the stopping point.");
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        int stoppingPoint = scanner.nextInt();

        // Sum the evens
        int sumOfEvens = 0;
        for (int even = startingPoint; even <= stoppingPoint; even += 2) {
            sumOfEvens += even;
        }

        // Print out the result
        System.out.println("The sum of evens from " + startingPoint + " to " + stoppingPoint + " is " + sum);
    }

So our new programmers usually are correctly decomposing the problem and are looking for ways to indicate the problem decomposition. The right way to indicate the problem decomposition is to reflect it with method decomposition.

Lots of nice things come from that method decomposition, but I think the most obvious one is that you no longer need those comments. If you use well named methods, the names of the methods tell me what they do, and the sequence of calls serve to narrate what's going on all on their own.

Class decomposition

Does the main belong in this class, EvenSummer? As I say in Where Should Main Live, I don't think so. I would move that main out into its own class. If you do that, that's a form of class decomposition: breaking down the responsibilities of a single class into multiple classes, each with a dedicated purpose.

What about the prompting? Should that be in the same class as the class that knows how to sum? What about the printing? It would be better if not and leave EvenSummer with only the responsibility and modeling of how to sum evens. Make it pure and have it be responsible for one thing only, managing the logic for summing evens.

So where would the input prompting and parsing and output go? Perhaps in a Driver class that would ask for input, and call into EvenSummer. How about a final program that looks like this (note that I'm including multiple files' contents here):

// In Main.java
public class Main {
    public static void main(String[] args) {
        Driver.sumUserSuppliedEvens();
    }
}

// In Driver.java
public class Driver {
    public static void sumUserSuppliedEvens() {
        int startingPoint = requestStartingPoint();
        int stoppingPoint = requestStoppingPoint();
        int sumOfEvens = EvensSummer.sumEvensUntil(startingPoint, stoppingPoint);
        outputSumOfEvens(sumOfEvens, startingPoint, stoppingPoint);
    }

    private static int requestStartingPoint() {
        System.out.println("Type in a non-negative integer for the starting point.");
        Scanner scanner = new Scanner(System.in);
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        return scanner.nextInt();
    }

    private static int requestStoppingPoint() {
        System.out.println("Type in a non-negative integer for the stopping point.");
        Scanner scanner = new Scanner(System.in);
        // Ignore user input errors, and assume they'll type in a non-negative integer.
        return scanner.nextInt();
    }

    private static void outputSumOfEvens(int sum, int startingPoint, int stoppingPoint) {
        System.out.println("The sum of evens from " + startingPoint + " to " + stoppingPoint + " is " + sum);
    }
}

// In EvensSummer.java
public class EvensSummer {
    public static int sumEvensUntil(int start, int until) {
        int sumOfEvens = 0;
        for (int even = start; even <= 10; even += 2) {
            sumOfEvens += even;
        }
        return sumOfEvens;
    }
}

We've now decomposed our logic into classes, each with its own responsibility and within those classes, we've decomposed our logic into methods, each with its own responsibility.

Why do this?

Readability It's a lot easier to read the decomposed code than the code that is not decomposed. It's easier for the author and for the code reviewers to understand what the program does as a whole, and what each part does and how they fit together. And we don't need comments: the code is self-documenting!
Maintainability When you break up your methods and classes like this, it's much easier to make updates to your code later. In part, that's because of the improved readability -- you can see where the seams are in the code, and so where the appropriate places are to layer in new functionality. Hopefully, the stepwise way in which I was able to add prompting the user for two different inputs helps drive that home. And as I added more code, it didn't make it harder to read my program. Compare my method decomposed version to the version that did not decompose the methods.
Debuggability A lot of debugging involves visually inspecting your code to see what could have gone wrong. Breaking the code into distinct, dedicated methods in distinct, dedicated classes makes it easier for you to train your focus on just what that specific method is supposed to do, and whether it does it correctly. Your mental model gets simpler because each method is simpler. There are also benefits having to do with the impossibility of one bit of code's influencing another: with the non-decomposed, long line of code implementation, every bit of that implementation can share the same variables and possibly accidentally overwrite or misuse them. When you decompose your logic, you break your logic into smaller scoped code blocks that don't influence each other.
Reusability Single purpose methods are easier to reuse. You can call the same method from different points in your code. That's not so obvious here, in this example, because we're not reusing any code. A lot of your early programs don't have much code reuse. And when you do need to reuse code, you'll probably naturally refactor your code so you have a method you can reuse. So this reason may fall a bit flat for you, even though it's true.
Testability Your textbooks will likely tell you that it's easier to test individual, small, single purpose methods and small, dedicated classes. That's very true, and important. But you're also probably not writing testing code right now. So you'll have to trust us that this is true, and we're promoting good habits for later, when you do write tests.

How do I know when to decompose?

It's often a judgement call when to decompose, and I would bet most students think that decomposing their methods and classes is adding a bunch of unnecessary overhead. Their programs are small, and they wrote them, so they can track what's going on in them.

But your programs will grow with time, and developing and practicing the good habits of decomposing them now, when it's actually easier because they are small, will serve you well.

Plus, you sometimes do iterate on your same program. Homework assignments occasionally ask you to enhance an earlier assignment. So you may be, even in the beginning of your programming journey working on smaller programs, in the business of maintaining your programs. And you certainly have to try to fix bugs. Even for these small problems, the benefits of decomposition come out, despite the fact that you can sometimes overcome the deficits of not decomposing by exerting some extra brain power.

Here's a great tip. Beginning programmers do have an instinct for this: as I said above, it's why they insert newlines into their code, and it's why they add comments to blocks of code. I see it when they ask me for help, and when we're looking at their code together, they tell me "This part here gets the starting number from the user; then this part gets the ending number; then this part sums the evens; and then this part prints out the answer." If you ever find yourself doing any of these things -- inserting blank lines, adding comments, narrating to yourself or someone else what each part does -- that's a very strong signal you should decompose your logic!

Other notes

Notice that in my decomposed example, I create two instances of Scanner. I could choose to make one instance and pass it in to each of the methods: e.g.

    public static void main(String args[]) {
        Scanner scanner = new Scanner(System.in);
        int sumOfEvens = sumEvensUntil(requestStartingPoint(scanner), requestStoppingPoint(scanner));
        outputSumOfEvens(sumOfEvens);
    }
// Updates to requestStartingPoint and requestStoppingPoint ommitted

I also don't call close on my Scanners (and so close never gets called on those InputStreams, System.in). That's not great, but let's limit the contents of what we're dealing with. Closing resources is usually a later topic in a new Java programmer's journey.

Good Habits For New Java Programmers

Mark Rubin — Wed, 31 Aug 2022 18:49:48 +0000

tl;dr Here's the habits List

What's this all about?

I'm an instructor for an introductory Java course. My students are learning Java mostly on their own using course texts, and I'm available for general help, and I review their code assignments.

There are some common themes developing for the advice I've been giving my students on Java style, so I'm collecting that advice here. I use "Java style" loosely, covering more than just what a code formatter might handle, to include some basic, good habits that will help the students write cleaner, easier to read, and easier to maintain Java programs: topics such as variable, class, and method naming; what makes a good comment; some language usage tips (e.g. == true is redundant); and more.

Although all the discussions are presented in the context of Java programming, they are generally good programming tips and extend naturally to other languages. For example, picking meaningful names for identifiers is important for any language you program in.

Habits?

I'm framing these tips as helpful habits to develop because that framing helps motivate why I'm advocating for them in my code reviews of students' programs. The small size and short-lived nature of those programs obscure the value of the advice a bit. So some of the advice may seem like it isn't so important for this or that specific program, but it is a good habit nonetheless, and developing it will pay off in the long run with larger programs.

For example, I push for giving variables meaningful names; but a variable named just p is not hard to track in a ten line program, and that program, just a one-off homework assignment, isn't going to be maintained over time or read by lots of people. So what's the harm in a one letter name in this case? Well, at the very least, the harm is in not developing the right habits. Following my advice will help students start off straight away doing the right things. Bad habits are hard to break, and if you're a student reading this, if you continue with your programming, you'll be glad you developed the right habits early on. I wish I had gotten this advice and developed those habits sooner than I did.

Developing these habits can add a bit of extra mental work as you start out, but not that much, and it's very worth it. If the other reasons I offer for each item don't hit home, you will just have to trust me on the good habits bit. Sometimes you have to learn the whats before the whys.

Checklist

If you're a student, it might be useful to maintain a checklist based off of these habits I'm asking you to develop. Then you have a structured way to review your code before you submit it. Reviewing and applying the checklist will help you develop the right habits and will reduce how much of your assignment I'll ask you to revise and improve your grade.

List of habits:

Meaningful Names
Naming Conventions
Default To private Access Modifiers
Writing Good Comments
Always Use Braces For if/else
== true and == false Are Redundant
Use Your IDE's Code Formatter
What's A Good Error Message
How To Get Out Of Main And Reduce Static
Method Decomposition And Class Decomposition
Where Should Main Live
How To Order Your Fields And Methods

Meaningful Names

Mark Rubin — Wed, 31 Aug 2022 16:35:25 +0000

This is part of a brief series on Good Habits For New Java Programmers.

Use meaningful names for variables

A meaningful name for a variable is one that tells us what the variable represents or what it's used for or how it's used in the program, and does not use too much shorthand. Let's dive in.

Don't name variables after the type they store

There's a tendency to use a letter or name for a variable that simply matches the type of the variable.

Consider this:

double d;

The name d is not meaningful. It hints that the variable stores a double, but it doesn't tell me what this double is going to be used for or what it's storing. Likewise, array and doubles in

double[] array = new double[10];
double[] doubles = new double[10];

are not examples of meaningful names. The first name, array, conveys to me that the variable stores an Array, and the second name, doubles, conveys that variable stores an Array of doubles. But knowing the types are not enough to know what the variables do in our program. Neither tells me why I'm going to be storing an array of doubles or how this Array is going to be used in the program.

Let's imagine that these doubles are meant to store prices. Then these would be more meaningful names:

double price;
double[] prices = new double[10];

You should get even more specific, if that makes sense:

double coffeePrice;
double[] coffeePrices = new double[10];

Don't over abbreviate your variable names

There's a tendency to needlessly abbreviate otherwise meaningful names. Here are some examples someone might use instead of double sellerCost;
double sc;
double sCost;
double selCost;

Those are in increasing order from worst to better (though none great), as the increased number of letters gives more hints as to what the abbreviation is for. Don't force yourself or your readers to guess how to interpret a vanity license plate style abbreviation -- just make it obvious:
double sellerCost;
It doesn't cost you much: you type a few extra letters the first time, and then your IDE/programming environment will give you autocomplete suggestions for the next time you want to refer to that identifier. And it dramatically improves the readability and maintainability of the code. Not just for me, the reader, but for you: when reading an expression such as sc - bp you will have to translate sc into "seller cost" and bp into "buyer price" to understand what the expression is doing. That translation adds a mental tax. You don't have to pay that tax when reading sellerCost - buyerPrice.

Sure, a name like purchPrice for a purchase price isn't that hard to expand in your head to "purchase price", but why not just write it out in full to save us all the mental step? purchasePrice is a better name for your variable than purchPrice, even if purchPrice isn't terrible.

Don't tack on numeric values to variable names to distinguish them

Sometimes you need to represent two of a similar kind of value: maybe you have two kinds of prices, one for the cost of something to you, the seller, and one for the sales price that the buyer pays. Use meaningful names to distinguish your variables for them. costPrice and salesPrice, for example. Or maybe sellerCost and buyerPrice. You get to think of what names make sense, but you have to put some effort into it.

Don't use price1 and price2. The 1 and the 2 don't tell you or me (the reader of your code) anything meaningful that helps us to remember or keep track of the difference in what the variables represent. Will you remember as your program expands which of price1 or price2 holds the cost to the seller or the cost to the buyer? Later when you read a line of code
double profit = price1 - price2;
will you be able to see easily if that's a mistake and should be the other way around? Should it be
double profit = price2 - price1;?

It's much easier to understand your program if instead, you had
double profit = buyerPrice - sellerCost;
That will help you make sure your programs are correct, help your readers of your code help you improve it, and make it easier to build on your program later: if you have to come back and add more functionality later -- let's say sales tax -- it'll be much easier to know which of those variables you should be applying the sales tax to.

There are counterexamples (aren't there always?), but in general, you should ban the usage of number suffixes on your identifiers: don't tack on a 1 or a 2, etc. onto any identifier.

Use meaningful names for methods, classes, parameters, and everywhere else, too.

A method named doIt() doesn't have a helpful name. Do what? What happens when you add another method? How will you distinguish them? Perhaps with a method named doIt2()? Which one does what?

That doIt example may seem far-fetched, but it's not uncommon to see students create a method getPrice() (much more meaningful than doIt(), for sure!) and then need another method to do something similar, and create a getPrice2(). Instead, it would be better to have methods named, for example, getSellerCost() and getBuyerPrice(). Now you know and I know what these methods should do.

The same sort of thing applies to class names or wherever you come up with names in your programs. If you see a method signature
private void getProfit(double d1, double d2)
do you know which double is intended to hold seller's cost and which is intended to hold the buyer's price? How about
private void getProfit(double sellerCost, double buyerPrice)? That makes it clear.

I admit it: there are exceptions

Okay, so, it's true that sometimes, the language for the subject matter we're talking about naturally uses abbreviated terms or single letters for things. For example, when we talk about points on a plane, we use x and y to represent the coordinates of that point. In that case, it does make sense to have variables named x and y: e.g.

public class Point {
    float x;
    float y;

    public Point(float x, float y) {
        this.x = x;
        this.y = y;
    }
}

And it is convention to use i, j, k for iterators in for loops. E.g.

for (int i = 0; i < 10; ++i) {
   // Your code here
}

If there's a natural abbreviation that does not require work to decipher, it's okay to use that: String ceoName; is perfectly readable and much more natural than String chiefExecutiveOfficerName;

And sometimes, you really are writing a generic function that takes two of a primitive type, say, and it makes sense to write something like:

public void reverse(String string)

public int sum(int num1, int num2)

You can go too far

My experience is that there's little danger here for new programmers, but it's also true that a name like itemPriceIncludingAllTaxesAndDiscounts is a bit of a mouthful and takes up a lot of room on a line. Naming is hard and involves judgement, but in general, err towards more informative names than less informative ones.

Sometimes examples you find do not use meaningful names

Sometimes the texts you use or examples you look up on the web will not do as I'm saying.

That's unfortunate, since it means some of your authorities on how to write code will be tacitly contradicting my advice. And it's common (advisable, even!) to copy and paste examples to help you get started on some piece of code, and it's easy to miss the need to go back and clean up the example. But do go back and clean up what you copied to use meaningful names.

Perhaps there's some good fortune in the fact that you'll run across plenty of code that doesn't do as I say, though. I'm hoping you'll realize that when you read that code, you find it harder to read and harder to learn from than you would have had your source used more meaningful names. Maybe that will help this topic seem like sound advice, rather than just a set of rules to follow.

If you're here, you might also want to read Naming Conventions.

DEV Community: Mark Rubin

Where should main live

Does main still contain too much?

Naming Conventions

Class and Interface names begin with an uppercase letter

Variable, method, parameter names should always begin with a lowercase letter

Use CamelCase for class, variable, parameter, and method names

There are other rules

Writing Good Comments

Don't narrate your code

So what comments should I include?

Grammar

Comments should be grammatical

Comments should not contain abbreviations

Comments should be complete sentences that end with periods.

== true and == false are Redundant

Always Use Braces For if/else

The danger

Style consistency

Default To private Access Modifiers

How To Get Out Of Main And Reduce Static

In the beginning...

main is simply an entry point. It is not for modeling your data or problem space.

Don't get stuck in the static trap

Summary

What's A Good Error Message

Error messages should be specific and actionable

Tell them about all their errors at once, if you can

Don't use computer jargon in your error messages

Error messages should be grammatical, and usually should be complete sentences

Double check your error messages

How To Order Your Fields And Methods

Be conventional

Put public things before private things

If possible, calling methods go on top of called methods

Violate these rules if it makes sense

Where does main go?

Method Decomposition And Class Decomposition

In the beginning...

Decomposing even this small example

Class decomposition

Why do this?

How do I know when to decompose?

Other notes

Good Habits For New Java Programmers

What's this all about?

Habits?

Checklist

List of habits:

Meaningful Names

Use meaningful names for variables

Don't name variables after the type they store

Don't over abbreviate your variable names

Don't tack on numeric values to variable names to distinguish them

Use meaningful names for methods, classes, parameters, and everywhere else, too.

I admit it: there are exceptions

You can go too far

Sometimes examples you find do not use meaningful names

Don't get stuck in the `static` trap