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. You also agree that by submitting a pull request for this project, your contribution will be licensed under the Open Source license for this project.

• 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.