就Unity 3D的C# 而言，有什麼是你code review時一看到就是問題的地方？

01-13

我先來一個：用了GameObject.Find

謝邀。

因項目而異，真的不好一概而論。比如

1、GameObject.Find用在Update()中顯然是個問題，但是用在Start()中並不是大問題。除非初始化確實很慢需要優化。

2、項目大小可預計的情況下，用組件的方式擴展功能還挺酷的，要什麼功能拖上去即可。

3、項目體量較大而且未來還要繼續擴展的話（比如很多國產網遊），過多依賴編輯器賦值（比如拖上去一大堆組件）的行為都需要斟酌一下。很多時候通過數據表配置參數穩妥得多。

真正顯然有問題的情況，想到一個：濫用Coroutine而導致調用順序不明確的情況。

還有一個：過多惰性初始化（比如濫用單例），導致變數初始化順序不明確的情況。

其實這兩個問題在伺服器端也存在。

在循環或刷幀的時候用Camera.main

這是官方文檔的說明：This property uses FindGameObjectsWithTag internally and doesn"t cache the result. It is advised to cache the return value of Camera.main if it is used multiple times per frame.

再補充一個：在循環或刷幀的時候用Input.touches，Unity文檔里是這麼說的（注意最後那個括弧里的Allocates temporary variables）

Returns list of objects representing status of all touches during last frame. (Read Only) (Allocates temporary variables).

很容易忽略的一個地方，這麼好的一個回答居然連一個贊都沒有，真是想刪答案。

if if if if if

switch case case case case

任何超過兩層大括弧的嵌套和超過三層大括弧的匿名函數或 try catch 嵌套

出現兩次以上相同結構的代碼塊

超過20行的函數

超過200行的非工具類

magic number

不正確命名

數據和邏輯混寫

屁大點功能都要開個 monobehaviour 類

還有n多...

看題主的意思應該是指Unity有哪些「坑」。

這是我之前寫過的一篇文章，裡面有介紹一些需要注意的地方：

金曉宇：Unity的「優化」——不要劣化你的代碼zhuanlan.zhihu.com

除此之外，再說幾個容易忽略的：

1.小心SetParent。有的團隊在管理對象時會把對象掛來掛去，比如把對象放回池子里時，會把對象掛在某個節點下面方便管理。殊不知當調用SetParent(obj)時，unity為了保證子對象相對父對象的transform不變，會重新計運算元對象的local position(這可以通過調用setParent(obj, false)來避免)，除此之外，還會涉及到樹結構的遍歷操作，以及觸發onTransformChanged消息。當物體有mesh collider時，更是會觸發PhysX重建碰撞體，造成非常高的開銷。

2.緩存Camera.main。

3.Unity5.4版本之前的loadAsset()。在5.4之前，loadAsset()會調用AssetBundle.GetPathRange()，而這個方法的消耗異常的高。因為它是一個線性的搜索過程，造成搜索過程比較耗時。嚴格說來這是個bug，並且在5.4已經修復了。

float類型比較用==

謝邀。其實大部分問題可以通過靜態代碼檢查發現可以參考【敏捷開發】使用靜態分析優化Unity代碼這篇文章。

我們項目的每日CodeReview其實並不嚴格，主要會看一些代碼規範，是否有冗餘代碼，實現方案，設計架構是否完善，是否有類似功能，是否可以抽象，以及開發時的思路方法等，更偏向溝通交流和學習。

比如GetComponent，每幀都在用

比如dictionary的數據結構，每幀都在遍歷

比如一個mono裡面update函數什麼都沒有寫，你還留了這個函數在代碼裡面

現在就想到這些，哈哈

調用一個介面怎麼能有問題呢，要看具體使用情況吧

前段時間接盤了一個項目，來答一波。

FindChild 拖出去打死

各種奇怪變數名拖出去打死

各種奇怪方法名拖出去打死

各種不用了的變數和方法不注釋拖出去打死

Update 里寫了if else 百來行拖出去打死

再就是注意控制好協程和invoke的使用。

想到再更～

虛擬現實增強現實