Good practice/optimizing your plugins ?

All your other points were correct, but this is wrong, wrong, wrong. You should always use the official API. Only go into NMS/CB code if the official API lacks what you need. In the case of setting blocks, the official API works fine.

Although I agree, an official world.setTypeIdAt(x,y,z,id,data) that bypasses block creation WOULD be nice, but that's something that you should submit a pull request for.

I don't pretend to speak for everyone, but I am often:

1.) Very busy
2.) Writing my own projects
3.) Very very busy

Writing wiki articles is pretty much out of the question. I know Grum, Tahg, Evil, and Co. are also very busy people with lives, and that's why it's hard to get a response out of them at times.

You will likely learn the fastest by:

1.) Contributing to existing projects. Large projects (Read: Bukkit, Citizens, Spout, Craftbook, etc) often have a ticket or bug reporting section with miles of entries and reports. Find an issue that seems simple, track down the bug or write the feature, submit a pull request.

Doing this will give you a better understanding of how larger projects work, how to read code that you didn't write, and emphasize the importance of comments.

2.) Talk with developers in IRC. At lot of bukkit developers spend time in IRC, and you can often catch snippets of wisdom or help for your problems much more quickly there. Provided you aren't rude about it.

3.) Trial and Error...And Error. You will learn 10x more from trying and trying on a project until you succeed then memorizing a tutorial. They have a place and a purpose, but they are not perfect.

 

hehe... take a look at my plugins... they are getting better (codewise) as I'm keeping refactoring them... and yeah I know that of lot of the good plugin developers are quite busy... but some aren't.

And I agree, learning by looking into other code helps a lot...

 

@all knowledgeable programmers :

What are good coded Bukkit plugins?

 

Not many. The problem is half of the plugin devs are people that learned java just because of bukkit. We probably have a lot more inexperienced programmers than the rest of the internet.

 

Ok,
then I download some plugins and look at the sources
and write a wiki article, about my view ...
Maybe a good Bukkit dev, or the community can correct me^^

 

@Afforess
I highly doubt they would accept a pull req like that because of the general idea of having everything nicely organized into sections and their opinion on helper methods. I've personally always hated how verbose it is to set the type of a block, and this would really be nice to have if there is a possibility.

 

I updated the wiki:

http://wiki.bukkit.org/Common_Coding_Etiquette

Please correct my english and more^^

 

I usually create as many lines as possible. It makes no difference when the code is compiled, as the blank lines are not compiled.

 

I try to take as many lines as possible, just so that people can understand it easier.

 

Same. Reducing the lines does nothing except make the code uglier.

 

The goal is not to make all things in one line,
the target is to make it as short as understandable,
e.g.

Code:java

   public void calculateFirst() {
        for (int i = 0; i < 100; i++) {
            System.out.println("a " + i);
            System.out.println("aa " + i);
            System.out.println("aaa " + i);
        }
        for (int i = 0; i < 90; i++) {
            System.out.println("b " + i);
            System.out.println("bb " + i);
            System.out.println("bbb " + i);
        }
    }
 
    public void calculateSecond() {
        for (int i = 0; i < 100; i++) {
            System.out.println("a " + i);
            System.out.println("aa " + i);
            System.out.println("aaa " + i);
            if (i < 90) {
                System.out.println("b " + i);
                System.out.println("bb " + i);
                System.out.println("bbb " + i);
            }
        }
    }
 
    public void calculateThird() {
        for (int i = 0; i < 100; i++) {
            action("a", i);
            if (i < 90) {
                action("b", i);
            }
        }
 
    }
 
    private void action(String string, int i) {
        System.out.println(string + " " + i);
        System.out.println(string + string + " " + i);
        System.out.println(string + string + string + " " + i);
    }

There are many books about code style^^

 

The reason there is no documentation for bukkit plugins is because this is a general programming problem.
To solve it in java, you need more knowledge of java in general.

I do know a free solution to that, a free online book: thinking in java:
Try for example chapter 9 to learn what will be the best way to store your data.
homepage:
http://www.mindview.net/Books/TIJ/
a direct link to the book:
http://www.cs.hut.fi/Docs/Eckel/TIJ3ed/TIJ3.htm

Note that it i not possible to get version 4 for free in any legal way.

 

In Germany we have a cooler address:

http://openbook.galileocomputing.de/javainsel/

in english:

JAVA is an island

a good english source:
http://sourcemaking.com/refactoring

 

And Comments, Comments and more Comments...
If you ever want to expand your plugin in 1 or 2 month, without comments it will take you long just to figure out what does what.

e.g.: in my newest plugin I have 56% source code lines, 34% comments and 10% blank lines.

 

Actually for optimizing your plugins you wouldn't actually want too many comments. Why? Well for one, contrary to popular belief comments do slow down code because even though they aren't used as anything they are still run through by the compiler because it has to know not to use something that is there. Second they take up space for instance if you have this code

Code:

int i = 2;
int x = 5;
while(i < x)
{
i++;
System.out.println("hi");
}

and

Code:

int i = 2; // a counter
int x = 5; // a target
while(i < x) //a while loop to print out hi a bunch of times
{
i++;
System.out.println("hi");
}

Even though they do the EXACT same thing the second version takes up more space even if it is just a few more bytes more, if comments were like this in a fairly big plugin it could potentially take up a few megabytes more than needed. Now this isn't to say that comments shouldn't be used but if you have good programming habits then you should make variable/method/class names self-explanatory as to what they are for and really only need comments when you are doing something that is fairly confusing.

P.S. I want everyone to keep in mind that this is geared twords optimization NOT being user friendly.

 

The compiler strips out comments. Try compiling some code with comments then decompiling it again.

 

Not always. It depends on the compiler. I once had a mentor who was working for a company writing software for them and he was done but he needed to make it run just a few seconds faster. He took out all of the comments because he was out of ideas and it ran about 4 seconds faster. This has happened to me a few times before. I commented out a section of code to try something out and then found out it worked and deleted the commented out code and it suddenly got smaller.

 

Do you have anything to back up this claim?

 

1. The story about my mentor - no because if he gave me his code he would get fired/sued
2. You can try the second thing about it getting smaller yourself. You have to look closely because it was only a kilobyte or so in a 15 - 20 megabyte plugin (at least for me).

 

A source would be interesting.

But thanks to Jogy,
most thinks (like i++, for, ..) are self-explanatory.
If not, create a inner method with a cool name^^
Don't forgot to documentate method to generate javadocs, if it is necessary.

 

If you are commenting on whitespace, it dosent effect speed at all. you could have hundreds of lines of nothing and the compiler would just egnore it.

 

Test 1:

Source (open) Source (close)

Code:

public class CommentsTest {
    /**
     * Method description ...
     */
    public static void main(String[] args){
        System.out.println("Hello World!");
        // this is a comment
        /* this is another comment
        (blocky!) */
        /** A javadoc comment for no reason ...
        */
    }
}

Test 2:

Source (open) Source (close)

Code:

public class CommentsTest {
    public static void main(String[] args){
        System.out.println("Hello World!");
    }
}

Try 1: Compiled using javac.exe via command-line, jdk1.6.0_25 (64 bit)
Execution code: "javac CommentsTest.java" (no additional flags)

Test 1: Output: CommentsTest.class - 430 bytes
Test 2: Output: CommentsTest.class - 430 bytes

Try 2: Compiled using Eclipse, configured to use the same JDK as above

Test 1: Output: CommentsTest.class - 540 bytes
Test 2: Output: CommentsTest.class - 540 bytes

In both tries, the generated bytecode from test 1/2 was exactly the same (also content-wise).
Eclipse added in some more stuff that I can't really identify - but still exactly the same in both versions of the code (with & without comments).

I personally never heard of anyone using a different compiler than the one provided by the JDK (is there even another one?). IDEs generally also fall back to JDK to compile Java code.

Conclusion: The JDK compiler completely ignores comments and doesn't output them to a class file, thus leaving out comments doesn't effect runtime performance at all.

Feel free to test it out by yourself, if you find anything that proofs the opposite, feel free to post it - but in a way that is convincing and that we can at best reproduce ourselves (which is not in the style of "someone once deleted a bunch of comments and the output was different", btw).

 

1. There are plenty of different compilers for java. People make their own compilers for no reason all the time.
2. For the story with my mentor I had forgotten that he was a C++ programmer using a completely different environment so forget I ever wrote that.

 

btt ...
Has someone check the wiki?
Has someone more usefull tipps?

http://wiki.bukkit.org/Common_Coding_Etiquette

 

My only tip: Don't try to create bukkit plugins without enough knowledge of Java and general programming techniques (OOP, primarily).

What a ton of developers here are doing is learning the very basics of Java through doing a plugin - which they'll eventually release as soon as it "works" (in terms of: it somehow comes close to doing what it should do and doesn't throw exceptions).

I'm not telling anyone to become a complete expert at programming in Java before giving a shot at coding a plugin.
But for god's sake, at least learn what you essentially have to know! And don't release a crappy plugin just because it was your first try! Of course you keep gaining experience the more you work with bukkit, and everyone started small somewhere, but you can't start off of nothing!

That being said, I'd like to quote @Rednax_ from above:

Most of the "tips" mentioned here are part of very essential Java techniques. These can be found tons of times around the web, they don't apply only to bukkit at all.

The only thing that would be justified IMO are things that directly belong to the bukkit API, techniques that build on it (BlockStates, Commands, Events ...), but a lot of them can already be found in the Resources sub-forum.

 

Some interesting things can be found in these forum,
but there is not quick overview that explain special bukkit features,
e.g. EVENTS are thrown before the action happen.

Also I am not sure, if the ressource-index is up to date,
e.g. the Register lib is inactive and Vault is a better choice

 

well... I use and looked at a lot of plugins... and some have some cool features... so I look at that code.. and sometimes that code looks .... NICE... and sometimes... ugly..

concerning the wiki (will read it in a second)...

what should go onto there is stuff like:
general event handling, e.g. checking if event is cancelled, how the priorties of the listener work etc
command registering, e.g. via own command classes
permission registering, e.g. not via the plugin.yml
and similar stuff... so all the stuff which make the plugins look so "nice" from the code aspect.

concerning books... Head First books are nice IMHO for beginners.. http://www.amazon.com/Head-First-Ja...9208/ref=sr_1_1?ie=UTF8&qid=1322691934&sr=8-1
and http://www.amazon.com/First-Design-...7124/ref=sr_1_2?ie=UTF8&qid=1322691934&sr=8-2

and with that... DESIGN PATTERNS ... read about it, think about it.. and write some neater code because of it..

 

I have head firsts java, very good. If you don't want to buy a book, the oracle tutorials are the next best thing. I highly recommend you don't do thenewboston's tutorials.

 

Yes,
these stuff are important ...
There are much good threads,
but it is hard to find them.

For event I like this one:
http://forums.bukkit.org/threads/getting-your-priorities-straight-the-plugin-version.788/