Part 1: Syntax and Code Conventions

Nov 18, 2016
Part 1: Syntax and Code Conventions
  • Crash Course to Java

    Part 1: Syntax, Code Conventions, and other fancy words



    There are a few things that will be helpful to know as you continue in this guide and in your other Java learning pursuits. Let's talk about those first!

    Section A: Definitions
    JVM (Java Virtual Machine): The JVM is the virtual machine that executes java bytecode. It does not understand Java source code, which is why you compile your .java files into .class files that are understandable by the JVM. The JVM and the functionality involved is why Java is known as the "write once, run anywhere" language. It has implementations for different systems and aims to achieve the same results regardless of what system the bytecode is run on.

    JRE (Java Runtime Environment): The JRE contains the libraries, the JVM, and any other components needed to run applications written in Java. Two other technologies are also included in the JRE: Java Plug-in, which allows applets to run in popular browsers, and Java Web Start, which deploys standalone applications over a network.

    JDK (Java Development Kit): The JDK contains everything contained in the JRE, plus tools like compilers and debuggers specifically for developing applets and applications.

    Object: An object is essentially a container for a set of states/behaviors and methods to interact with them. For example, a dog has several different states - fur color, name, breed and behaviors like barking or eating. An object is an instance of a Class.

    Class: A class is sort of like a template for Objects. It's where you define the behaviors and states that the object of that type contains, and where you can define default values for states. Keeping with the dog example, a Class would be where you would say "a dog has fur color which defaults to brown, a name that you define when creating a new dog", etc.

    Methods: A method is the behavior of the object. This is where the logic is written and where states/data is manipulated.

    Instance Variables: The 'states' of objects we've been talking about are defined with instance variables. These serve the purpose of keeping track of what states any particular object is in at any given time.

    Constant: A constant is a variable whose value does not and cannot change. These are most often prefixed with "final", and are also often declared static as well. Enums like Bukkit's ChatColor class are similar to constants, only more versatile. They can be associated with data like how Bukkit's Material enums have their ids associated.

    Section B: Primitive Types
    In Java (and most other languages) there is a set of primitive types which you use to store the most basic types of data. These are somehow used in everything you make, even if you don't end up directly writing them yourself. They are the basic building blocks of data manipulation.
    boolean: A boolean is about as basic as data storage can get while still being functional. It stores one of two possible states: true or false. If you simply need to store something like the state of something being enabled or disabled, a boolean is perfect for the job.

    byte: A byte is an 8-bit integer (whole number) value. This means it can store values between -128 and +127. You will likely not be using this type much, but it can be used to save space in places where values won't need to be particularly large.

    short: A short is a 16-bit/2-byte integer value. They can store values between -32,769 and 32,767.

    int: An int is a 32-bit/4-byte integer value. An int can store values between -2,147,483,648 and 2,147,483,647. Most uses of integer values will use this data type.

    long: A long is a 64-bit/8-byte integer value. It can store values between -9,223,372,036,854,775,808 and 9,223,372,036,854,775,807. When an int cannot store values large enough for a particular use case, a long may be used.

    float: A float is a 32-bit/4-byte floating-point (having a decimal point) value.

    double: A double is a 64-bit/8-byte floating-point value.

    char: A char is a single 16-bit Unicode character. It can store values between '\u0000' (or 0) and '\uffff' (or 65,535).

    Special Mentions
    String: A string, while technically not a primitive type, will usually be an integral part of any program. It is made up internally of an array of chars.

    Wrapper Types: You may have seen the classes "Double", "Integer", etc. These exist so that you can use the primitive types in instances where an Object is required, such as when making a Collection of ints. These can be used interchangeably with primitive types, but primitive types should be used whenever possible.

    Section C: Modifiers
    Modifiers can be applied to Classes, variables, and methods to provide particular functionality in certain situations or to control access to data.

    Access Control Modifiers
    Public: Externally visible from an instance of the class. An example of this would be player.getWorld(). The method "getWorld" is public.

    Protected: The protected modifier makes something visible from inside the class, from the package the class is contained in, and from subclasses of the class.

    No Modifiers: Without adding any modifiers to something (e.g. a method "void doStuff() {}"), it is visible to the package the class is contained in.

    Private: The private modifier makes something visible only to the class which contains it. If you're simply storing some data to use later within the same class, this would be the way to go. There's no reason to make it accessible from outside the class if you won't ever need to do so.

    Other Modifiers
    Static: The static modifier is for creating class-level methods and variables. They will remain constant rather than being controlled by individual instances.

    Final: Using the final modifier is basically for saying "this variable will always be this, it will never change". When used in a class declaration, it disallows extension of it. Note: If used for an object instance, while the value itself will never change, that does not guarantee variables within the object cannot change.

    There are other modifiers you may come to use at some point, but those are the ones you will be using most often. Do research on your own to learn more about them.

    Section D: Naming Conventions
    Naming conventions are simply a set of rules to follow when deciding on names for your classes, packages, variables, methods, and so on. These conventions are followed mostly to make your code easier for yourself and others to read.
    If you don't follow proper naming conventions, you may come back to some code a year after writing it and be scratching your head trying to figure out what anything does. This is especially important for open-source work. Having clean, easy-to-read code makes you stand out as a programmer and makes it easier for others to use and work off of.

    Classes: Classes should be named in UpperCamelCase. Examples: Color, Button, Dog, EventHandler

    Methods: Methods should be named in lowerCamelCase. Examples: doStuff(), main(), onEnable(), sendMessage()

    Variables: Variables should also be named in lowerCamelCase. Examples: dogColor, dogName, pluginInstance, commandHandler

    Packages: Packages should be in lowercase. The structure of your packages generally should follow this rule: <reversed.domain.name>.<project name>[.<sub.packages>]. This is the standard to avoid clashes. If you don't own a domain name, something like io.github.yourname.projectname or com.gmail.youremail.projectname can suffice. Example: org.bukkit.block.

    Constants: Constants should be in uppercase. Example:
    public static final int MAX_MOB_HEALTH = 40;
    This applies to enum constants like Bukkit's ChatColor class as well.

    Another important part of naming conventions is giving things meaningful names. A method that sends a message to a player should not be called "s". It should be called "send", or even better "sendMessage". A variable keeping track of health shouldn't be called "h". It should be called "health" or even "healthPoints", or at least "hp".

    If you're worried about people stealing your code... don't be. When you're working for Google, then you can start worrying about protecting your code. Until then, it's more valuable to you to keep your code clear and understandable than the value it could gain from protecting it from theft.

    Continue the guide in Part 2!
  • Loading...
  • Loading...