Coding_Standard

The LUTE coding standard is meticulously crafted to ensure that the source code is both comprehensible for users and straightforward for contributors to maintain.

Typical Class Layout

using UnityEngine;

    /// <summary>
    /// Description of the component.
    /// </summary>
    public class MyComponent : MonoBehaviour
    {
        [Tooltip("Tooltip comment displayed in the editor.")]
        [SerializeField] protected float myProperty = 10f;

        protected virtual void MyMethod(){ }

        /// <summary>
        /// Documentation comment for public property.
        /// </summary>
        public virtual float MyProperty { get; set; }

        /// <summary>
        /// Documentation comment for public method that can be overrided.
        /// </summary>
        public virtual void DoSomething()
        {
        }

    }

Things to note:

• Remove any unused using declarations to help with compilation and build times.
• Editor code goes in the Editor folder in the project view.
• All public classes, structs, enums and class members should be documented using xml comments.
• You can document private and protected members if you want to, but ALL public members should have at least a summary comment and tooltip.
• Serialized fields should NEVER be public. Use a public accessor property to access the field if external access is required.
• All serialized fields should have a Tooltip attribute.
• All methods should be declared virtual and use protected instead of private. This allows for easy inheritance and extension (at the cost of some performance).
• Braces go on a newline and typically use tabs for spacing.

Contributing

We welcome pull requests from everyone. By contributing to this project, you agree to abide by the Code of Conduct.

• Fork and clone the LUTE repo.
• Make sure the tests pass locally (see the project readme for instructions).
• Make your change. Add tests for your change. Make the tests pass locally.
• Push to your fork and submit a pull request.

Your pull request will have a better chance of being accepted if you do the following:

• Send one pull request for each new feature / bug fix. It's time consuming to review multi-feature changes and we won't merge a change unless we know exactly what it does.
• Write tests for each change / new feature (not always possible)
• Follow our coding standard (see above)
• Write a good commit message.