) alot of flaming on these forums as to why most scripts dont get committed.However, other than in some sparse comments from L2J devs regarding some contributions I've never seen any kind of "Coding style guide" on this forum (correct me if I'm wrong... maybe I just didnt notice it).
I think it would make your (the L2J devs team) and the community's lives easier if there were clear rules as far as coding style.
It would not only make everything that gets committed easier to read/understand and more standardized, but it would also give some guidelines to people who want to contribute code to L2J as to "what they should at least do in order for their contribution to be even looked at by the team", and they'd know that if they followed those guidelines they'd have much more chances that what they contributed would be committed as the code would be cleaner and therefore much easier to correct if there are mistakes.
I'd like to suggest a few coding style rules if I may:
Javadoc/commenting:
Every class/interface/enum should be commented as to what its purpose is, general use, etc... and the name of the author.
Also, EACH METHOD in that class should be commented clearly to state what it does
Easily understandable class/interface/method names
Class, Interface, Enum and method names should be easily understandable.
Avoid abusing if/else if
Please, for the love of whatever god you believe in, go easy on the if/else if!
It just makes your code confusing for no good reason and makes it harder to debug/fix/maintain later on for just that reason.
There are tons of situations when you can avoid using intricate if/else if statements, make sure there's no other way before you go and do something like this (what follows is what NOT TO DO):
Code: Select all
if(whatever >= 2){ if(whateverelse.equals("hello")) { // do something } else if(whateverelse.equals("me")) { // do something } else { // do something }}else if(whatever < 1){ // do something}else{ // do something}Organize your thoughts on paper before you start coding. Make sure you didnt forget anything so that you dont have to go back and modify things afterwards, this ends up creating a mess in your code and others have a hard time making sense of it.
Code for others!
There's a great deal of chance that others will end up reading, expanding, modifying your code. Remember this when coding and commenting your code. Try to make their life easier!
Think about maintainability and expandability
This is CRUCIAL and it's one thing that forgotten 99% of the time in contributions.
We make something "that works fine" but we forget that it will later need to be maintained, expanded and/or improved in the futuer. Think about this when you're coding, program in a way that it will be easy for yourself or someone else to get in there and modify the code without breaking everything.
Avoid at all costs code that breaks!
Desing your code so that all hell doesnt break loose whenever something goes wrong or when it gets modified.
Think about making your scripts modular(if it's a larger script) with standardized in/out methods. This way if you need to update/maintain/modify a module, you only need to modify that part and you dont need to go and modify tons of other stuff in your script.
Dont be a jackass
So you're contributing something. Honestly and from the bottom of my heart thank you for putting your heart into this and keep up the good work.
However, dont be a jackass about it! Others before you have contributed as much and even much more than you have. Remain humble, others have things to learn from you, but you also have things to learn from others.
Keep trying
Your contribution didnt get committed for which ever reason? Ask why and what you should change to make it committable and keep working on it until it's good enough! Because "your script works fine on your server" doesnt mean that it will get committed. There are alot of things to take in consideration, and the "retail-like" thing is just one of them (and not even the most important in alot of cases). Security, efficiency, low ressource usage, maintainability, etc... are just as important if not more!
Variables
The names of variables should always be clear and easy to understand.
They should be all at the top of the class so they can be found easily later.
Variable names
Be consistent and always use the same style when coming up with variable names. They should be similar all through your script and follow general coding conventions.
from: http://docs.oracle.com/javase/tutorial/ ... ables.html
Think about ressource usage!Variable names are case-sensitive. A variable's name can be any legal identifier — an unlimited-length sequence of Unicode letters and digits, beginning with a letter, the dollar sign "$", or the underscore character "_". The convention, however, is to always begin your variable names with a letter, not "$" or "_".
Always code thinking about the best way to accomplish what you set out to do while using as little ressources as possible. Think about memory leaks and such as well.
There is a garbage collector, that's true, but remember to release your variables when they're not needed anymore. It's easy to end up with variables "lost" that the garbage collector cannot get to if you dont remember to release them.
Example:
Code: Select all
public class TestClass{ int value; public TestClass(int value){ this.value = value; }}Code: Select all
public class TestClass2{ private TestClass test; public TestClass2(TestClass test){ this.test = test; } public void cleanup(){ test = null; }}Code: Select all
public class TestClass3{ private TestClass2 test; public TestClass3(TestClass2 test){ this.test = test; } public void cleanup(){ test.cleanup() test = null; }}Dont do spaghetti code! Take an hour or two to read a bit about design patterns!
This is the most important part!!!
Please visit both links!
http://en.wikipedia.org/wiki/Spaghetti_code
http://www.javacamp.org/designPattern/
) 
| Eclipse Temurin 21 
| MariaDB 11.3.2 
| L2J Server 2.6.3.0 - High Five 
