Kódolási irányelvek – MRTK2

Ez a dokumentum az MRTK-hoz való hozzájáruláskor követendő kódolási alapelveket és konvenciókat ismerteti.

---

Filozófia

Legyen tömör, és törekedjen az egyszerűségre

A legegyszerűbb megoldás gyakran a legjobb. Ez az irányelvek egyik legfontosabb célja, és minden kódolási tevékenységnek a célnak kell lennie. Az egyszerűség része a tömörség és a meglévő kóddal való konzisztensség. Próbálja meg egyszerűnek tartani a kódot.

Az olvasóknak csak hasznos információkat biztosító összetevőkkel kell találkozniuk. Például azokat a megjegyzéseket, amelyek a nyilvánvaló adatokat újraértelmezik, nem biztosítanak további információt, és növelik a zaj és a jel arányát.

Tartsa egyszerűnek a kódlogikát. Ne feledje, hogy ez nem a legkevesebb sor használatát, az azonosítónevek vagy a kapcsos stílus méretének minimalizálását, hanem a fogalmak számának csökkentését és az ismerős mintákon keresztüli láthatóság maximalizálását ismerteti.

Konzisztens, olvasható kód létrehozása

A kód olvashatósága az alacsony hibaarányokkal korrelál. Törekedjen könnyen olvasható kód létrehozására. Törekedjen olyan kód létrehozására, amely egyszerű logikával rendelkezik, és újra felhasználja a meglévő összetevőket, mivel az a helyesség biztosításában is segít.

A létrehozott kód minden részlete számít, a helyesség legalapvetőbb részleteitől az egységes stílusig és formázásig. A kódolási stílust konzisztensen tarthatja a már létezőkkel, még akkor is, ha az nem felel meg az Ön igényeinek. Ez növeli a teljes kódbázis olvashatóságát.

Összetevők konfigurálásának támogatása a szerkesztőben és futásidőben

Az MRTK a felhasználók széles halmazát támogatja– azokat, akik szívesebben konfigurálják az összetevőket a Unity-szerkesztőben, és betöltik az előfabsokat, valamint azokat, akiknek futásidőben kell példányosítaniuk és konfigurálnia az objektumokat.

Minden kódnak működnie kell úgy, hogy egy összetevőt hozzáad egy GameObject elemhez egy mentett jelenetben, és példányosít egy összetevőt a kódban. A teszteknek tartalmazniuk kell egy tesztesetet az előfabsok példányosítására és a példányosításra, az összetevő futásidőben történő konfigurálására.

A play-in-editor az első és elsődleges célplatform

A Play-In-Editor az iteráció leggyorsabb módja a Unityben. A gyors iterálási módszerek lehetővé teszik, hogy ügyfeleink gyorsabban fejlesszék a megoldásokat, és további ötleteket próbáljanak ki. Más szóval az iteráció sebességének maximalizálása lehetővé teszi ügyfeleink számára, hogy többet érjenek el.

A szerkesztőben minden működjön, majd bármely más platformon működjön. Maradjon a szerkesztőben. Egyszerűen hozzáadhat egy új platformot a Play-In-Editorhoz. A Szerkesztőben való lejátszás nagyon nehéz, ha az alkalmazás csak egy eszközön működik.

Új nyilvános mezők, tulajdonságok, metódusok és szerializált magánmezők hozzáadása körültekintően

Minden alkalommal, amikor nyilvános metódust, mezőt és tulajdonságot ad hozzá, az az MRTK nyilvános API-felületének részévé válik. A mezőkkel [SerializeField] megjelölt privát mezők a szerkesztő számára is elérhetővé teszik a mezőket, és a nyilvános API-felület részét képezik. Mások használhatják ezt a nyilvános metódust, egyéni előtagokat konfigurálhatnak a nyilvános mezővel, és függőséget vállalhatnak rajta.

Az új nyilvános tagokat alaposan meg kell vizsgálni. A jövőben minden nyilvános mezőt fenn kell tartani. Ne feledje, hogy ha egy nyilvános mező (vagy szerializált magánmező) típusa megváltozik, vagy el lesz távolítva egy MonoBehaviour-ból, az másokat is tönkretehet. A mezőt először elavultnak kell lennie egy kiadáshoz, és meg kell adni a függőségeket áttelepítő személyek módosításainak migrálására szolgáló kódot.

Írási tesztek rangsorolása

Az MRTK egy közösségi projekt, amelyet számos közreműködő módosít. Előfordulhat, hogy ezek a közreműködők nem ismerik a hibajavítás/szolgáltatás részleteit, és véletlenül megszakítják a funkciót. Az MRTK minden lekéréses kérelem végrehajtása előtt folyamatos integrációs teszteket futtat. A teszteket megszakító módosításokat nem lehet beadni. Ezért a tesztek a legjobb módja annak, hogy mások ne törik meg a funkciót.

Ha kijavít egy hibát, írjon egy tesztet, hogy a jövőben ne álljon vissza. Funkció hozzáadásakor írjon teszteket, amelyek ellenőrzik, hogy a funkció működik-e. Ez a kísérleti funkciók kivételével minden felhasználói felületi funkcióhoz szükséges.

C# kódolási konvenciók

Szkriptlicenc-információk fejlécei

Az új fájlokat közreműködő Összes Microsoft-alkalmazottnak az alábbi szabványos licencfejlécet kell hozzáadnia az új fájlok tetején, pontosan az alább látható módon:

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT License.

Függvény- és metódusösszegző fejlécek

Az MRTK-nak közzétett összes nyilvános osztályt, struktúrát, enumerálást, függvényt, tulajdonságot, mezőt pontosan az alábbiak szerint kell leírni:

/// <summary>
/// The Controller definition defines the Controller as defined by the SDK / Unity.
/// </summary>
public struct Controller
{
    /// <summary>
    /// The ID assigned to the Controller
    /// </summary>
    public string ID;
}

Ez biztosítja a dokumentáció megfelelő generálását és terjesztését az összes osztályhoz, metódushoz és tulajdonsághoz.

A megfelelő összefoglaló címkék nélkül elküldött szkriptfájlok el lesznek utasítva.

MRTK-névtérszabályok

A Mixed Reality Eszközkészlet funkcióalapú névtérmodellt használ, ahol az összes alapszintű névtér a "Microsoft.MixedReality.Toolkit" névtérrel kezdődik. Általában nem kell megadnia az eszközkészlet-réteget (például: Core, Providers, Services) a névterekben.

A jelenleg definiált névterek a következők:

• Microsoft.MixedReality.Toolkit
• Microsoft.MixedReality.Toolkit.Boundary
• Microsoft.MixedReality.Toolkit.Diagnostics
• Microsoft.MixedReality.Toolkit.Editor
• Microsoft.MixedReality.Toolkit.Input
• Microsoft.MixedReality.Toolkit.SpatialAwareness
• Microsoft.MixedReality.Toolkit.Teleport
• Microsoft.MixedReality.Toolkit.Utilities

A nagy mennyiségű típusú névterek esetében elfogadható, hogy korlátozott számú alnévteret hozzunk létre a hatókörkezeléshez.

Ha kihagyja egy interfész, osztály vagy adattípus névterét, a módosítás le lesz tiltva.

Új MonoBehaviour-szkriptek hozzáadása

Amikor új MonoBehaviour-szkripteket ad hozzá egy lekéréses kérelemmel, győződjön meg arról, hogy az attribútum minden AddComponentMenu alkalmazható fájlra alkalmazva van. Ez biztosítja, hogy az összetevő könnyen felfedezhető legyen a szerkesztőben az Összetevő hozzáadása gomb alatt. Az attribútumjelölő nem szükséges, ha az összetevő nem jelenik meg a szerkesztőben, például egy absztrakt osztályban.

Az alábbi példában az itt található csomagnak meg kell töltenie az összetevő csomaghelyét. Ha elemet helyez el az MRTK/SDK mappában, akkor a csomag SDK lesz.

[AddComponentMenu("Scripts/MRTK/{Package here}/MyNewComponent")]
public class MyNewComponent : MonoBehaviour

Új Unity inspector-szkriptek hozzáadása

Általában próbálja meg elkerülni, hogy egyéni vizsgálószkripteket hozzon létre az MRTK-összetevőkhöz. További többletterhelést és a Unity-motor által kezelhető kódbázis kezelését is biztosítja.

Ha felügyelői osztályra van szükség, próbálja meg használni a Unityt DrawDefaultInspector(). Ez ismét leegyszerűsíti a felügyelői osztályt, és a munka nagy részét a Unityre bízza.

public override void OnInspectorGUI()
{
    // Do some custom calculations or checks
    // ....
    DrawDefaultInspector();
}

Ha egyéni renderelésre van szükség az inspector osztályban, próbálja meg használni a és EditorGUILayout.PropertyFielda parancsotSerializedProperty. Ez biztosítja, hogy a Unity megfelelően kezelje a beágyazott elő- és módosított értékek renderelését.

Ha EditorGUILayout.PropertyField az egyéni logika egyik követelménye miatt nem használható, győződjön meg arról, hogy az összes használat egy EditorGUI.PropertyScopekörbe van burkolva. Ez biztosítja, hogy a Unity megfelelően renderelje az ellenőrt a beágyazott elő-és módosított értékekhez az adott tulajdonsággal.

Továbbá próbálja meg díszíteni az egyéni vizsgáló osztály egy CanEditMultipleObjects. Ez a címke biztosítja, hogy a jelenetben több objektum is kijelölhető és módosítható legyen. Minden új vizsgálóosztálynak tesztelnie kell, hogy a kód működik-e ebben a helyzetben a helyszínen.

    // Example inspector class demonstrating usage of SerializedProperty & EditorGUILayout.PropertyField
    // as well as use of EditorGUI.PropertyScope for custom property logic
    [CustomEditor(typeof(MyComponent))]
    public class MyComponentInspector : UnityEditor.Editor
    {
        private SerializedProperty myProperty;
        private SerializedProperty handedness;

        protected virtual void OnEnable()
        {
            myProperty = serializedObject.FindProperty("myProperty");
            handedness = serializedObject.FindProperty("handedness");
        }

        public override void OnInspectorGUI()
        {
            EditorGUILayout.PropertyField(destroyOnSourceLost);

            Rect position = EditorGUILayout.GetControlRect();
            var label = new GUIContent(handedness.displayName);
            using (new EditorGUI.PropertyScope(position, label, handedness))
            {
                var currentHandedness = (Handedness)handedness.enumValueIndex;

                handedness.enumValueIndex = (int)(Handedness)EditorGUI.EnumPopup(
                    position,
                    label,
                    currentHandedness,
                    (value) => {
                        // This function is executed by Unity to determine if a possible enum value
                        // is valid for selection in the editor view
                        // In this case, only Handedness.Left and Handedness.Right can be selected
                        return (Handedness)value == Handedness.Left
                        || (Handedness)value == Handedness.Right;
                    });
            }
        }
    }

Új ScriptableObjects hozzáadása

Új ScriptableObject-szkriptek hozzáadásakor győződjön meg arról, hogy az CreateAssetMenu attribútum minden alkalmazható fájlra alkalmazva van. Ez biztosítja, hogy az összetevő könnyen felderíthető legyen a szerkesztőben az objektumlétrehozás menüiben. Az attribútumjelölő nem szükséges, ha az összetevő nem jelenik meg a szerkesztőben, például egy absztrakt osztályban.

Az alábbi példában az Almappát szükség esetén az MRTK almappával kell kitölteni. Ha egy elemet helyez el az MRTK/Providers mappában, akkor a csomag Szolgáltatók lesz. Ha elemet helyez el az MRTK/Core mappában, állítsa ezt "Profilok" értékre.

Az alábbi példában a MyNewService | A MyNewProvider nevet az új osztály nevével kell kitölteni, ha van ilyen. Ha egy elemet a MixedRealityToolkit mappába helyez, hagyja ki ezt a sztringet.

[CreateAssetMenu(fileName = "MyNewProfile", menuName = "Mixed Reality Toolkit/{Subfolder}/{MyNewService | MyNewProvider}/MyNewProfile")]
public class MyNewProfile : ScriptableObject

Naplózás

Új szolgáltatások hozzáadásakor vagy meglévő funkciók frissítésekor érdemes lehet debugUtilities.LogVerbose naplókat hozzáadni érdekes kódhoz, amely hasznos lehet a jövőbeli hibakereséshez. Itt van egy kompromisszum a naplózás hozzáadása és a hozzáadott zaj, valamint a nem elég naplózás (ami megnehezíti a diagnózist).

Egy érdekes példa, ahol a naplózás hasznos (az érdekes hasznos adatokkal együtt):

DebugUtilities.LogVerboseFormat("RaiseSourceDetected: Source ID: {0}, Source Type: {1}", source.SourceId, source.SourceType);

Az ilyen típusú naplózás segíthet az olyan problémák észlelésében, mint a https://github.com/microsoft/MixedRealityToolkit-Unity/issues/8016, amelyeket az észlelt eltérő forrás és a forrás elveszett eseményei okoztak.

Kerülje a naplók hozzáadását minden keretben előforduló adatokhoz és eseményekhez – ideális esetben a naplózásnak az "érdekes" eseményeket kell lefednie, amelyek különböző felhasználói bemenetek alapján történnek (azaz egy felhasználó "kattintással", valamint a naplózható módosítások és események készletével). A "felhasználó még mindig kézmozdulatot tart" állapot minden képkockát naplózva nem érdekes, és túlterheli a naplókat.

Vegye figyelembe, hogy ez a részletes naplózás alapértelmezés szerint nincs bekapcsolva (ezt engedélyezni kell a diagnosztikai rendszer beállításaiban)

Szóközök és lapok

A projekthez való hozzájáruláskor ügyeljen arra, hogy a tabulátorok helyett 4 szóközt használjon.

Térköz

Ne adjon hozzá további szóközöket szögletes zárójelek és zárójelek közé:

Nem ajánlott

private Foo()
{
    int[ ] var = new int [ 9 ];
    Vector2 vector = new Vector2 ( 0f, 10f );
}

Ajánlott

private Foo()
{
    int[] var = new int[9];
    Vector2 vector = new Vector2(0f, 10f);
}

Elnevezési konvenciók

Mindig használja PascalCase a tulajdonságokhoz. A legtöbb mezőhöz használhatócamelCase, a és PascalCaseconst a static readonly mező kivételével. Az egyetlen kivétel ez alól az olyan adatstruktúrák esetében van, amelyek megkövetelik, hogy a mezők szerializálva legyenek a JsonUtilityhasználatával.

Nem ajánlott

public string myProperty; // <- Starts with a lowercase letter
private string MyField; // <- Starts with an uppercase letter

Ajánlott

public string MyProperty;
protected string MyProperty;
private static readonly string MyField;
private string myField;

Hozzáférés-módosítók

Mindig deklarál egy hozzáférés-módosítót az összes mezőhöz, tulajdonsághoz és metódushoz.

• Minden Unity API-metódusnak alapértelmezés szerint meg kell lennie private , kivéve, ha felül kell bírálnia őket egy származtatott osztályban. Ebben az esetben protected a következőt kell használni:

• A mezőknek mindig , és tulajdonsággal publicprotected kell lenniükprivate.

• Kifejezéstestű tagok és automatikus tulajdonságok használata, ahol lehetséges

Nem ajánlott

// protected field should be private
protected int myVariable = 0;

// property should have protected setter
public int MyVariable => myVariable;

// No public / private access modifiers
void Foo() { }
void Bar() { }

Ajánlott

public int MyVariable { get; protected set; } = 0;

private void Foo() { }
public void Bar() { }
protected virtual void FooBar() { }

Kapcsos zárójelek használata

Minden utasításblokk után mindig használjon kapcsos zárójeleket, és helyezze őket a következő sorba.

Nem ajánlott

private Foo()
{
    if (Bar==null) // <- missing braces surrounding if action
        DoThing();
    else
        DoTheOtherThing();
}

Nem ajánlott

private Foo() { // <- Open bracket on same line
    if (Bar==null) DoThing(); <- if action on same line with no surrounding brackets
    else DoTheOtherThing();
}

Ajánlott

private Foo()
{
    if (Bar==true)
    {
        DoThing();
    }
    else
    {
        DoTheOtherThing();
    }
}

A nyilvános osztályoknak, a szerkezeteknek és az enumerálásoknak a saját fájljaikban kell lennie

Ha az osztály, a szerkezet vagy az enumerálás privátvá tehető, akkor nem baj, ha ugyanabba a fájlba belefoglaljuk. Ez elkerüli a Unity fordítási problémáit, és biztosítja a megfelelő kód absztrakcióját, valamint csökkenti az ütközéseket és a kompatibilitástörő változásokat, amikor a kódnak változnia kell.

Nem ajánlott

public class MyClass
{
    public struct MyStruct() { }
    public enum MyEnumType() { }
    public class MyNestedClass() { }
}

Ajánlott

 // Private references for use inside the class only
public class MyClass
{
    private struct MyStruct() { }
    private enum MyEnumType() { }
    private class MyNestedClass() { }
}

Ajánlott

MyStruct.cs

// Public Struct / Enum definitions for use in your class.  Try to make them generic for reuse.
public struct MyStruct
{
    public string Var1;
    public string Var2;
}

MyEnumType.cs

public enum MuEnumType
{
    Value1,
    Value2 // <- note, no "," on last value to denote end of list.
}

MyClass.cs

public class MyClass
{
    private MyStruct myStructReference;
    private MyEnumType myEnumReference;
}

Enumerálások inicializálása

Annak érdekében, hogy az összes enumerálás megfelelően legyen inicializálva 0-tól kezdve, a .NET egy rendezett parancsikont ad a szám automatikus inicializálásához az első (kezdő) érték hozzáadásával. (pl. 1 érték = 0 A fennmaradó értékek nem szükségesek)

Nem ajánlott

public enum Value
{
    Value1, <- no initializer
    Value2,
    Value3
}

Ajánlott

public enum ValueType
{
    Value1 = 0,
    Value2,
    Value3
}

Rendelési enumerálás a megfelelő bővítményhez

Kritikus fontosságú, hogy ha egy enumerálást a jövőben valószínűleg meghosszabbítanak, az alapértelmezett értékeknek az Enumerálás felső részén történő megrendeléséhez ez biztosítja, hogy az enumerálási indexek ne legyenek hatással az új kiegészítésekre.

Nem ajánlott

public enum SDKType
{
    WindowsMR,
    OpenVR,
    OpenXR,
    None, <- default value not at start
    Other <- anonymous value left to end of enum
}

Ajánlott

/// <summary>
/// The SDKType lists the VR SDKs that are supported by the MRTK
/// Initially, this lists proposed SDKs, not all may be implemented at this time (please see ReleaseNotes for more details)
/// </summary>
public enum SDKType
{
    /// <summary>
    /// No specified type or Standalone / non-VR type
    /// </summary>
    None = 0,
    /// <summary>
    /// Undefined SDK.
    /// </summary>
    Other,
    /// <summary>
    /// The Windows 10 Mixed reality SDK provided by the Universal Windows Platform (UWP), for Immersive MR headsets and HoloLens.
    /// </summary>
    WindowsMR,
    /// <summary>
    /// The OpenVR platform provided by Unity (does not support the downloadable SteamVR SDK).
    /// </summary>
    OpenVR,
    /// <summary>
    /// The OpenXR platform. SDK to be determined once released.
    /// </summary>
    OpenXR
}

A bitmezők enumerálási használatának áttekintése

Ha lehetséges, hogy egy enumerálás értékként több állapotot is megkövetel, például: Handedness = Left & Right. Ezután az Enumert helyesen kell díszíteni BitFlagokkal, hogy megfelelően lehessen használni

A Handedness.cs fájl konkrét implementációval rendelkezik ehhez

Nem ajánlott

public enum Handedness
{
    None,
    Left,
    Right
}

Ajánlott

[Flags]
public enum Handedness
{
    None = 0 << 0,
    Left = 1 << 0,
    Right = 1 << 1,
    Both = Left | Right
}

Rögzített fájlelérési utak

Sztringfájlok elérési útjainak létrehozásakor, és különösen a rögzített karakterlánc-elérési utak írásakor tegye a következőket:

1. Amikor csak lehetséges, használja a C# API-jaitPath, például vagy Path.CombinePath.GetFullPath.
2. Használja a / vagy Path.DirectorySeparatorChar a parancsot a \ vagy a \\ helyett.

Ezek a lépések biztosítják, hogy az MRTK Windows- és Unix-alapú rendszereken is működjön.

Nem ajánlott

private const string FilePath = "MyPath\\to\\a\\file.txt";
private const string OtherFilePath = "MyPath\to\a\file.txt";

string filePath = myVarRootPath + myRelativePath;

Ajánlott

private const string FilePath = "MyPath/to/a/file.txt";
private const string OtherFilePath = "folder{Path.DirectorySeparatorChar}file.txt";

string filePath = Path.Combine(myVarRootPath,myRelativePath);

// Path.GetFullPath() will return the full length path of provided with correct system directory separators
string cleanedFilePath = Path.GetFullPath(unknownSourceFilePath);

Ajánlott eljárások, beleértve a Unity-javaslatokat

A projekt néhány célplatformjának figyelembe kell vennie a teljesítményt. Ezt szem előtt tartva mindig legyen óvatos, amikor a memóriát gyakran kódban, szoros frissítési hurkokban vagy algoritmusokban lefoglalja.

Beágyazás

Mindig használjon privát mezőket és nyilvános tulajdonságokat, ha a mezőhöz az osztályon vagy a szerkezeten kívülről van szükség hozzáférésre. Győződjön meg arról, hogy a privát mezőt és a nyilvános tulajdonságot közösen keresi meg. Így egy pillantással áttekinthetővé válik, hogy mi áll a tulajdonság háttérrendszerében, és hogy a mező szkripttel módosítható.

Megjegyzés

Az egyetlen kivétel ez alól az olyan adatstruktúrák esetében van, amelyek megkövetelik, hogy a mezők szerializálva legyenek a JsonUtilityhasználatával, ahol egy adatosztálynak rendelkeznie kell a szerializálás működéséhez szükséges összes nyilvános mezővel.

Nem ajánlott

private float myValue1;
private float myValue2;

public float MyValue1
{
    get{ return myValue1; }
    set{ myValue1 = value }
}

public float MyValue2
{
    get{ return myValue2; }
    set{ myValue2 = value }
}

Ajánlott

// Enable field to be configurable in the editor and available externally to other scripts (field is correctly serialized in Unity)
[SerializeField]
[ToolTip("If using a tooltip, the text should match the public property's summary documentation, if appropriate.")]
private float myValue; // <- Notice we co-located the backing field above our corresponding property.

/// <summary>
/// If using a tooltip, the text should match the public property's summary documentation, if appropriate.
/// </summary>
public float MyValue
{
    get => myValue;
    set => myValue = value;
}

/// <summary>
/// Getter/Setters not wrapping a value directly should contain documentation comments just as public functions would
/// </summary>
public float AbsMyValue
{
    get
    {
        if (MyValue < 0)
        {
            return -MyValue;
        }

        return MyValue
    }
}

Értékek gyorsítótárazása és szerializálása a jelenetben/előfabban, amikor csak lehetséges

A HoloLens szem előtt tartásával a legjobb, ha optimalizálja a teljesítményt és a gyorsítótár-hivatkozásokat a jelenetben vagy az előzetes verzióban a futásidejű memórialefoglalások korlátozásához.

Nem ajánlott

void Update()
{
    gameObject.GetComponent<Renderer>().Foo(Bar);
}

Ajánlott

[SerializeField] // To enable setting the reference in the inspector.
private Renderer myRenderer;

private void Awake()
{
    // If you didn't set it in the inspector, then we cache it on awake.
    if (myRenderer == null)
    {
        myRenderer = gameObject.GetComponent<Renderer>();
    }
}

private void Update()
{
    myRenderer.Foo(Bar);
}

Az anyagokra mutató hivatkozások gyorsítótárazása, ne hívja meg a ".material" nevet minden alkalommal

A Unity minden alkalommal létrehoz egy új anyagot, amikor a ".material" kifejezést használja, ami memóriavesztést okoz, ha nem tisztítja meg megfelelően.

Nem ajánlott

public class MyClass
{
    void Update()
    {
        Material myMaterial = GetComponent<Renderer>().material;
        myMaterial.SetColor("_Color", Color.White);
    }
}

Ajánlott

// Private references for use inside the class only
public class MyClass
{
    private Material cachedMaterial;

    private void Awake()
    {
        cachedMaterial = GetComponent<Renderer>().material;
    }

    void Update()
    {
        cachedMaterial.SetColor("_Color", Color.White);
    }

    private void OnDestroy()
    {
        Destroy(cachedMaterial);
    }
}

Megjegyzés

Másik lehetőségként használja a Unity "SharedMaterial" tulajdonságát, amely nem hoz létre új anyagot minden egyes hivatkozáskor.

Platformfüggő fordítás használata annak biztosításához, hogy az eszközkészlet ne törje meg a buildet egy másik platformon

• A használatával WINDOWS_UWP UWP-specifikus, nem Unity API-kat használhat. Ez megakadályozza, hogy a szerkesztőben vagy nem támogatott platformokon fussanak. Ez egyenértékű a UNITY_WSA && !UNITY_EDITOR és a használatával.
• A használatával UNITY_WSA UWP-specifikus Unity API-kat használhat, például a UnityEngine.XR.WSA névteret. Ez akkor fog futni a Szerkesztőben, ha a platform UWP értékre van állítva, valamint a beépített UWP-alkalmazásokban.

Ez a diagram segíthet eldönteni, hogy melyiket #if használja a használati esetektől és a várt buildbeállításoktól függően.

Platform	UWP IL2CPP	UWP .NET	Szerkesztő
UNITY_EDITOR	Hamis	Hamis	Igaz
UNITY_WSA	Igaz	Igaz	Igaz
WINDOWS_UWP	Igaz	Igaz	Hamis
UNITY_WSA && !UNITY_EDITOR	Igaz	Igaz	Hamis
ENABLE_WINMD_SUPPORT	Igaz	Igaz	Hamis
NETFX_CORE	Hamis	Igaz	Hamis

A DateTime.UtcNow előnyben részesítve a DateTime.Now értéket

A DateTime.UtcNow gyorsabb, mint a DateTime.Now. A korábbi teljesítményvizsgálatok során megállapítottuk, hogy a DateTime használata jelentős többletterhelést jelent, különösen az Update() ciklusban való használat esetén. Mások is ugyanezt a problémát tapasztalják.

Inkább a DateTime.UtcNow parancsot használja, hacsak nincs szüksége a honosított időpontra (ennek oka lehet, hogy meg szeretné jeleníteni az aktuális időt a felhasználó időzónájában). Ha relatív időpontokkal (azaz a legutóbbi frissítés és most közötti eltéréssel) foglalkozik, a legjobb, ha a DateTime.UtcNow használatával elkerüli az időzónák átalakításának többletterhelését.

PowerShell-kódolási konvenciók

Az MRTK-kódbázis egy része a PowerShellt használja a folyamatinfrastruktúrához, valamint különböző szkriptekhez és segédprogramokhoz. Az új PowerShell-kódnak a PoshCode stílust kell követnie.

Lásd még

C#-kódolási konvenciók az MSDN-ből