Golden Rules

Let's compile a list of Golden Rules for the Bukkit community. The Plugin Development forum is full of some of the worst code known to humanity. I hope this thread will help curb that.

All these rules are equal in importance, please feel free to add more Golden Rules or suggest why any of these shall be removed.

Golden Rule 1) Conventions, conventions, conventions.
Why? Readability of course! Study up, young padawan. This includes having your package names in all lowercase, and your class names in PascalCase
Golden Rule 2) Don't do 'public class Main extends JavaPlugin implements Listener'. Why not? Java has support for multiple classes. Use them. It will make your code cleaner.

Golden Rule 3) Don't have onCommand nonsense in your main class. Instead, create a new class, named CommandTest (replace 'Test' with whatever it is you want your command to be) and go from there.

Golden Rule 4) In your commands, before casting sender to Player check if it is an 'instanceof' Player. Ever wondered why running commands from console throws an error? This is why.

Golden Rule 5) For the love of god, don't use static variables or have static instances of your Main class. Yes I know sometimes you HAVE to, but seriously, try to avoid it. Why?

Golden Rule 6) Give each and every command a new class. I may make a post about doing this as it seems many people don't know how to do it...

Golden Rule Omega) Learn Java before coding plugins.

Nit picking (This is mainly for my sanity's sake)

§ Developing Bukkit plugins without prior knowledge of Java. People that do this really get on the nerves of many experienced devs. Learn Java before diving into Bukkit plugins. TheNewBoston has an excellent series for this. Some of the stuff is outdated, but the comments section has up-to-date help. You might want to read something like Java for Dummies and stuff like that to help you get on your feet.

§ Stop using Eclipse. Some people are going to get mad at this p ), but I would suggest switching to IntelliJ. Why? It will tell you when you have redundant or inefficient code. I've seen people using Lombok (ewwwww), IntelliJ has super helpful shortcuts that make Lombok redundant. Everyone I know that switched to IntelliJ love it



To all the experienced developers out there, please help expand this list by posting what you think are Best Practice, and maybe we can make a BCP (Best Common Practice) protocol for Bukkit plugins ;D

 

So does Eclipse. Eclipse is actually a pretty neat IDE. Maybe it doesn't have all the features you might want, but it's hardly a bad IDE. One thing Eclipse definitely has over IntelliJ is that there is no paid version of Eclipse. Don't get me wrong, I like IntelliJ too. But which one to use is mostly personal preference.

 

AdamQpzm Hence why I said I was starting to nit pick at that stage

 

Diamond rule is knowing Java before trying to code plugins. About everything else is caused due to lack of Java knowledge.

 

Another golden rule would be to do your own research instead of looking at videos, especially outdated ones. Read a book, become intrigued and get the drive to want to learn more.

As for the golden rule about commands contained within their own classes, the way I do it is have a CommandExecutor for each command. In that class, I handle command sub-commands by trimming the first argument of the args of the commands using the following:

Code:java

public static <T> T[] trim(T[] args) {
    return Arrays.copyOfRange(args, 1, args.length);
}

This code would be used as such - a simple /kit command:

Code:java

@Override
public boolean onCommand(CommandSender sender, Command cmd, String command, String[] args) {
 
    if (args.length < 1) {
        handleBaseCommand(sender);
        return false;
    }
 
    if (args[0].equalsIgnoreCase("create")) {
        createKit(sender, Utils.trim(args));
    } else if (args[0].equalsIgnoreCase("edit")) {
        editKit(sender, Utils.trim(args));
    } else if (args[0].equalsIgnoreCase("remove")) {
        removeKit(sender, Utils.trim(args));
    } else {
        spawnKit(sender, args);
    }
 
    return false;
}
 
private void handleBaseCommand(CommandSender sender) {
    sender.sendMessage("Usage: /kit create <kit name> - create a new kit");
    sender.sendMessage("Usage: /kit edit <kit name> - edit an existing kit");
    sender.sendMessage("Usage: /kit remove <kit name> - remove an existing kit");
    sender.sendMessage("Usage: /kit <kit name> - spawn an existing kit");
}

And so on. The code would be too long to paste here, but basically, in my createKit, editKit, removeKit and spawnKit methods, the args start from index 0, which I find to look nicer. I plan to make a more sophisticated method of handling sub-commands in the future.

 

Can you explain why not? I love having my commands in my main class for easy access. Just my personal preference.

 

Marten Mooij
Because your main class will be unreadable for someone who is not you if there are 100+ lines only for one onCommand(). (It looks unorganized and some people including me don't have time/don't want to analyze your code for half an hour just to find something)
Java supports multiple classes for a reason. So let's use them to make our code clearer.

 

Marten Mooij
Your personal preference is bad. Having all your commands in your main class destroys the readability. Having separate classes for each command will make it much more accessible, trust me. Instead of scrolling through hundreds, if not thousands of lines of code to debug an error in one command is definitely not a good practice.