Just had a thought after reading some other posts… will there be any sort of “encouraged code formatting” going on in plugins, or will it be left up to the author?
Some things I feel may qualify are the use of IRandomClass vs. RandomClass for interfaces, tabs vs. spaces, inline brackets or postfixed brackets (the proper way >:| ), etc. All in all rather minor things. Opinions?
I’m pretty sure somewhere, on the readme or something, it said to follow the oracle guidelines. I’m all for a custom one, but the oracle one works.
Oh yay, an official statement. I didn’t quite see that
It’s their plugin, so they set the standards for it. That being said, if their code style is too radical, I won’t waste my time trying to decipher it. 
I believe the posted guidelines are for contributing to the Sponge project, not specifically covering plugins (which is what the OP asked about specifically).
Ah, right. It is a good idea to just ask for people to adobt one for the entire community though.
I imagine people would probably use the official ones if they know they exist.
…right? …I’m probably dreaming of a perfect world
You are. Sorry to break your dream </3
For plugins it would be up to the plugin author. You can’t really enforce a style guideline on everyone for their individual style. That’s what teams are for. XD
I’m sure as usual it is suggested to try to conform to Oracle style guidelines just because they are fairly standard and make for readable code.
That’s basically what I said, only expanded a bit more.
@Zeus is right, I just basically expanded on his comment. That’s what I get for not reading everything.
What are the pros to using spaces over tabs? I’ve honestly never understood, except it takes longer to backspace 4 spaces than it does a tab.
Not only is it bad practice but for the sake of formatting, it makes things much easier to alter.
@Nentify
It is simply preference. There’s pros and cons to both but at the end of the day it’s whatever you work with best. Obviously that won’t fly when you’re following standards laid out for the project your working on.
@phroa
As for a style guideline, I recommend as stated by many to generally follow Oracle’s guideline, but that is mainly in terms of naming conventions. Other than that it comes down to a per-project basis and whatever the standards are for that project and the people involved. There’s no way someone making a plugin with sponge would see some “recommended standards” and simply follow it unless they had to.
As others have already stated, I think the code design should be up to the developers.
However, I think guidelines for plugin config-files would be something that could make the lives of server owners much easier.
For example, if there is a debug option it has to be at the end of the config file.
Or Min and Max ranges must be specifed by a comment in the config.
Or it should be clear if a time is specified in minutes or seconds.
Those are all problems I’ve encountered over the years as plugin developer and server owner.
Cheers.
@igwb
Eh, once again I feel that’s up to the developer. Placement of nodes in a configuration file means nothing to the interpreter. Alphabetize, sort by importance, category etc- in the end all of them will be loaded in. If the developer publicly released their plugin, it’s their job to comment the default configuration file in order to allow server admins to understand. Also if they’re taking the release seriously they would have adequate documentation somewhere.
If a plugin does not meet your standards, inform the developers and request that they listen to your ideas/suggestions, or move to another plugin (I understand you can’t always simply do this).
At the end of the day, no developer will really care to follow a configuration file style-guideline.
@wingz
I completly agree that it is the task of the developers to make sure that their plugins are easy and comfortable to use. Obviously plugins are written so people can benefit from them.
However I still think that it would be a good think to have a guideline for “best practice” config design. Nothing mandatory but rather a list of things one might simply not think about when developing a plugin.
These recommendations could be place at the end of the (hopefuly soon existing) plugin development tutorial. (cf. Plugin Tutorial (Eclipse) - Official BukkitWiki) The bukkit plugin submission guidelines even included hints on how to name and describe your plugin properly. (cf. BukkitDev: Project Submission Guidelines - Official BukkitWiki)
When I started developing plugins I would’ve been thankful for a hint to the right direction. Surely there will be many people new to plugin development that never realy thought about how they want people to use their plugin.
As with everything, if people realy don’t want to care, they won’t. But I don’t think that should be the reason to let those people down that do in fact care and could use a soft nudge into the right direction.
My main reason for being against having any sort of guidelines is because there is no way to say placing your nodes here or there is any better.
I would much prefer a tutorial of sense that can promote good practices such as commenting and using self-describing node names. You could have a header that describes an index listing of all node/sub-node ordering/positioning throughout the config of a basic plugin-generated file. Although to say “debugs should go on the bottom” is not only conflicting, but it also poses no real benefit unless enough people adopt it and even still you need to look for the node names…
The conflict: I would need to locate ALL debugs under the same super-node in order to keep them all in the same section (to put them all at the bottom). If I don’t, then debug.debug-startup would not be grouped with players.debug-claims which defeats the style guideline purpose… no?
I must agree. Perhaps I haven’t thought my original suggestion thru well enough.
I also agree that a tutorial promoting good practices would be terrific.
Something like
and other things that don’t come to my mind currently.
A tutorial like this could also be used as a reference when asking a developer to change something in his plugin.
PS: I’ve never seen a plugin with multiple debug nodes. Is that realy a thing?
