Naming and javadoc clarity #2258
Replies: 3 comments 3 replies
-
Can 100% agree with you on this, and I'm sure the other maintainers/contributors will also agree. There are a lot of niche things with the current codebase that have been stitched together and then things added on top of the stitches over the years with new major Minecraft updates and new maintainers of GP. The only reason we're hesitant to change things like this immediately is because of how massively adopted GP is and how it would cause a lot of breakages to the API. I believe the main attraction of GP is how simple and how reliable it is. If you take a peep at the roadmap in https://github.com/orgs/GriefPrevention/projects/1 you'll notice that That all being said, there is def a lack of documentation on these things. GP is fully open sourced including the docs, and I know some PRs for the docs would be loved. Instead of dogging on the how its currently setup, How would you like to see it be implemented? |
Beta Was this translation helpful? Give feedback.
-
Our current implementation of the different trust levels is utilizing enums, which is great. but it is limiting addons from creating custom levels. I think moving away from enums is a good start, similarly to how the Paper team is deciding to move away from enums with things like Biomes |
Beta Was this translation helpful? Give feedback.
-
As pretty much the only person actually putting javadocs on their changes, this feels kinda personal. Yeah, they aren't perfect, but something's better than literally nothing, which is what existed before. Seriously, check the git blame on pretty much any method with documentation actually in Javadoc format. Rather than attack the work that has gone in, maybe you could suggest improvements. On my end, after reading this, I'm feeling like maybe I should just stop bothering to document things if this is the thanks I'll get. I don't want to make this reply a personal attack on you either, so please forgive me if it does come across that way: |
Beta Was this translation helpful? Give feedback.
-
I was asked by @RoboMWM to share my rant at how bad the naming in this codebase is. Recently I've been working at implementing unified protection plugin service api and I spend horrendous amount of time trying to figure out which ClaimPermission is responsible for interactions with entities and only after talking to Robo I was informed that
ClaimPermission.Inventory
was the answer. That is straight up not acceptable. There's no mention of the actual responsibility of this enum value anywhere. Either it should have a separate enum value, have its name changed to reflect what it actually represents or at the very least have a javadoc explaining what it's for if there can't be any changes in the enum for any reason.Beta Was this translation helpful? Give feedback.
All reactions