Який із цих двох кодів "кращий"? Зробити локальну змінну чи змінну класу?

Я роблю більше ігор і задаю дурніші запитання.

Сподіваємось, цей дуже короткий. Я створюю дуже базовий клас, який просто переміщує об’єкт Player, застосовуючи силу до жорсткого тіла, але мені стало цікаво, чи слід робити класне посилання на rb або просто локальну змінну всередині Оновлення кожного кадру? (маючи на увазі, це вже існує в батьківському класі Monobehaviour.GameObject.

Мені цікаво, якщо виконання багатьох локальних змінних уповільнить цикл у цілому (під локальним я маю на увазі всередині самої функції, а не на вершині класу - сподіваюся, що ми використовуємо правильний термін).

Ось що я маю на увазі, два способи, які я думав зробити це:

public class Player : MonoBehaviour {

private void FixedUpdate()
{
    Rigidbody rb = GetComponent<Rigidbody>();

    float v = Input.GetAxis("Vertical");

    rb.AddForce(v * rb.transform.forward * Const.walkForce);
}
}

або ...

public class Player : MonoBehaviour {
Rigidbody rb;

private void Awake()
{
    rb = GetComponent<Rigidbody>();
}

private void FixedUpdate()
{
    float v = Input.GetAxis("Vertical");

    rb.AddForce(v * rb.transform.forward * Const.walkForce);
}
}

Взагалі, я виявив, що ви повинні розміщувати дані якомога вужче, щоб почати і розширити область, як ви виявите, що вам потрібно. Це означає, що якщо ви можете зробити його локальною змінною замість члена, ви, ймовірно, повинні почати з цього місця.

Це пояснюється тим, що вузька сфера зменшує кількість місць у коді, де потрібно обґрунтувати ці дані, і, таким чином, зменшиться кількість місць, які ви можете неправильно пояснити (що призводить до помилок).

Власне декларування локальних змінних ніколи не сприймає ефективності: вони дешеві, а сучасні компілятори можуть навіть оптимізувати "додаткові".

Ініціалізація їх може викликати занепокоєння; у вашому випадку ваше жорстке тіло піднімається щоразу через GetComponent, що має деяку ненульову вартість. Якщо ви знаєте, що жорсткий компонент корпусу не зміниться для цього конкретного ігрового об’єкта, ви можете переглянути його один раз і зберегти результат у змінній учасника та уникнути невеликих накладних витрат на виклик.

Малоймовірно, що накладні витрати за виклик будуть значущими лише в цьому випадку, але з часом це зробить для багатьох компонентів. Ви хочете застосувати профілер, щоб бути впевненим.

Отже, підсумовуючи: загалом, за замовчуванням робити речі максимально локальними, але в цьому випадку, мабуть, розумно зробити rbчлен, щоб ви могли здійснити пошук один раз Awakeі уникати необхідності робити кожен FixedUpdateвиклик.

Відповідь Джоша Петрі дуже хороша - ось додаткова перспектива.

Коли ви працюєте з кодом, який ви досить добре розумієте домен, ви можете застосувати змінні місця, де вони мають сенс.

Наприклад, якщо у мене є Personклас з waveGoodbyeметодом, можливо, мій клас раніше не мав handоб'єкта, і я можу оголосити його локально waveGoodbye. Тепер тут очевидно, що у людини є рука, тому ви, природно, можете заявити про це як про члена, Personне замислюючись над цим, але це ж питання стосується.

Якщо ви заявляєте на handмісцевому рівні, то пізніше ви можете додати karateChopметод, який також потребує допомоги. Це коли декларування змінних на локальному рівні може стати проблематичним - адже молодші розробники часто відступають від копіювання / вставки декларації, waveGoodbyeі тепер у вас є одна і та ж концепція, розташована у двох місцях. Будь-які зміни handтоді потрібно змінити в обох місцях, і таким чином починається пагорб мурашиних помилок.

Так що загалом,

1. Якщо ви впевнені у розміщенні декларації, додайте її до місця, де це має сенс.

2. Якщо ви не впевнені в собі, тоді запускайте локальний і не забудьте зробити рефактор, коли ви отримаєте потік повторного використання коду.
   
   

Редагувати: О, і не робіть тієї самої помилки, я витрачаю занадто багато часу на з'ясування, де розмістити ваші декларації. Важко зрозуміти структуру ваших даних наперед, і під час написання коду структура має спосіб розкрити себе.