1. Hey guys,

    I really love the Oxide coding community as everyone is very inclusive for the most part and make really great plugins. The code is essentially open source by design, but not by license or contributing directly to projects easily like on GitHub, so I thought I would contribute some ideas. Disclaimer: I work in open source coding building websites with Drupal, an open source PHP based CMS.

    The Drupal Community has a very strict set of Coding Standards by which developers are required to follow to contribute code back to the core and contribute other code. I'm not saying we require any of this, but it can be a great set of guidelines to avoid some pitfalls I have seen in various plugins I use on my server. Those include namespace collisions for commands, missing ResourceId, no HelpText integration, and poor Oxide API best practices.

    I would like to suggest we come up with a similar set of Oxide Plugin Coding Standards that can be referenced on this site to help address some of these issues moving forward. Yes, C# is pretty hard to mess up because it either compiles or not, but we have to think about how many different plugins interact together on a larger scale, especially Universal vs. game specific plugins. One of the things Drupal is known for is how many modules it has. Modules are basically plugins with a different namespace, but the idea is the same. Create an easy to follow standardization and no plugins break other plugins and everything works well together together as one. I think we can achieve this same harmony within our coding community.

    This post might not even belong only in the Rust Oxide section, but that's the only game I use currently for Oxide so that's where I felt it was best served for now.

    Thank you all for your time and effort on all these great plugins!

    Jason
     
  2. Wulf

    Wulf Community Admin

    A lot of this is documented in our plugin submission guidelines page. We really only set basic standards for functionality, not really a style of coding.
     
  3. I'm not trying to change the style of coding here, just standardize it more. Like all plugins should have a ResourceID, standard. Each command should be a unique namespace. That sort of thing. Just trying to pass along good sauce.
    [DOUBLEPOST=1494482503][/DOUBLEPOST]I know you are basically the judge, jury, and executioner on most things on the site Wulf, so maybe it would be easier to spread the load to ensure at least the basic standards are kept for new submissions or to act on issues like ResourceIDs and stuff. I'm not saying anything against you, as you seem to be more than one person with what you do around here, but just some thoughts I wanted to share with the community on things instead of commenting on specific plugins. We can definitely share the load on this.

    Thanks again,

    Jason
    [DOUBLEPOST=1494483010][/DOUBLEPOST]I think implementing a coding standard for uploading a patch file for a feature request, documentation(HelpText), or bug fix on a project would be a great way to keep the master source in sync without additional source files being uploaded in comments. That's how we handle updates to source code on Drupal.org in the issue queues. The maintainer can easily apply the patch if it's against the master source code and code they like.
     
  4. Wulf

    Wulf Community Admin

    ResourceId won't be used down the road, so we don't enforce that. Commands are not going to be required to have their own namespace either, though they should be easily customizable. We are also planning on changes in the way plugins are hosted and contributed to, but that won't happen with the current site.
     
  5. I look forward to being able to contribute smaller bits of code easier like features and bug fixes. Thanks again for all you do man :)