I'm trying to get on the L2jOrg train as it walks, but I confess it is very difficult.
The code lacks comments and referential documentation,
we should keep the code cleaner, and it is easy just applying a few principles of clean code. So I'm opening this issue to discuss our most important principles to keep their code clean, and I decided to share the best ones with the world, from my point-of-view
Bad code works until it's the year 2,000. Bad code is difficult to understand, more complex than it should be, not easy to test, and it makes other developers seethe with frustration. While it might take longer to write clean code in the short term, it's beyond established that writing clean code will save everyone time, effort.
But there's always room to learn. No one writes clean code from the beginning.
Clean Code Principles
Clean code doesn't rely on language-specific rules. Instead, it relies on language-agnostic principles agreed upon by the developer community. The Clean Code should be present at Datapack or Java Codes, all assets should implement it.
KISS: Keep It Simple Stupid. A design principle originating from the U.S. Navy that goes back to 1960 already. It states that most systems should be kept as simple as possible (but not simpler, as Einstein would have said). Unnecessary complexity should be avoided. The question to ask when you're writing code is "can this be written in a simpler way?"
DRY: Don't Repeat Yourself. Closely related to KISS and the minimalist design philosophy. It states that every piece of knowledge (code, in this case) must have a single, unambiguous, authoritative representation within a system (codebase). Violations of DRY are referred to as WET: We Enjoy Typing, Write Everything Twice, Waste Everyone's Time.
YAGNI: You Aren't Gonna Need It. A developer should not add functionality unless deemed necessary. YAGNI is part of the Extreme Programming (XP) methodology, which wants to improve software quality and increase responsiveness to customer requirements. YAGNI should be used in conjunction with continuous refactoring, unit testing, and integration.
Composition over inheritance: Not an acronym, sadly. It's a principle where you design your types over what they do instead of over what they are. It's explained in more detail in this video and few examples in java here
The composition is favoured over inheritance by many developers, because inheritance forces you to build a taxonomy of objects early on in a project, making your code inflexible for changes later on.
Favour readability: It's not because a machine can read your code that another human can. Particularly when working with multiple people on a project, always favour readability over conciseness. There's no point in having concise code if people don't understand it.
There are many ways to make your code more readable. Two examples are placing common numbers into well-named constants (e.g. const CACHE_TIME = 200;) and creating long names instead of shorter ones (e.g. calculateDestinationTime
over calcDestTime
, which doesn't tell as much, for example, I don't know if in fact is a method to calculate destination time.
Practice consistency: This is arguably the overarching principle of all clean code principles. If you decide to do something a certain way, stick to it throughout the entire project. If you have no choice but to move away from your original choice, explain why in the comments.
Boy Scout Rule : Leave the campground better than you found it. This last one is about my perception, when you touch someone else's code you should let it better than you found it.
Conclusion
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
What I am proposing is not just to take everything that has been done so far and start to tweak it, but whenever you tweak something new, try adding comments, refactoring method and variable names so that they are self-explanatory.
This will certainly make the code easier and more attractive to contribute.