我還是很新的，所以在這個問題上，我的問題不是爭論或小問題，但在某些閱讀過程中，有些東西讓我感到奇怪。使用不同的數字變量類型
我的設想是，當電腦速度慢，內存昂貴時，使用正確的變量類型比現在更爲必要。現在人們似乎已經放鬆了一點，記憶容易一些。例如，您可以在任何地方看到此示例代碼：
for (int i = 0; i < length; i++)
int？ （-2,147,483,648至2,147,483,648）的長度？ Isnt字節（0-255）是更好的選擇？所以我很好奇你的意見和你認爲是最佳實踐，我不認爲這會被用於只是因爲縮寫「int」對初學者來說更直觀......或者記憶變得如此便宜我們真的不需要關注這些小事情，因此我們應該使用很長的時間，以便我們可以確保使用的其他數字/類型（在合理的範圍內）可以自動進行投射？
......或者我只是因爲自己對這種事情感到愚蠢嗎？
Luca Bolognese在他的博客中發佈this。
下面是相關的部分：
現在通常內存很便宜，因爲您不必擔心它，您可以關注更重要的編程細節。把它想象成管理記憶，你必須做的越少，整體效率就越高。最終它與抽象層次有關，如果你不需要控制所有的齒輪和輪子的工作方式，那麼最好不要修補它們。
在實踐中，您通常會使用整數或長整數（如果您需要額外的大小）。除非我正在優化，否則我現在不會關心自己。並記住優化的黃金法則除非必須，否則不要優化。先編寫代碼，然後根據需要進行優化。
另一個類似的情況是設計數據庫模式時。我經常看到人們設計一個模式，只允許他們在NVARCHAR列上需要的東西。對我來說，這是荒謬的，因爲它是一個可變長度的列，所以你不會浪費空間，並給自己足夠的空間，避免出現問題。我曾經爲一家在網站上進行內部登錄的公司工作;一旦我升級到IE8的網站開始崩潰。經過一番調查後，我發現日誌模式只允許32個字符的瀏覽器id字符串，但是當使用IE8（使用Vis Studio和其他擴展名）時，瀏覽器id字符串增長到32以上，導致網站無法工作。當然可以有更嚴格的長度檢查和更好的錯誤處理，但是通過允許256而不是32來防止崩潰，但我們不會截斷數據分貝。
我不是在暗示你使用字符串，並且Int64是你所有的數據類型（不超過我建議你把所有的sql列設置爲NVARCHAR（4000）），因爲你失去了可讀性。但選擇一個合適的類型並給自己很多填充。
我記得有人設計一個專欄作爲VarChar（11）'。當我們得到需要'VarChar（12）'的客戶時會發生什麼？ – ChaosPandion 2010-03-16 03:01:28
使用小於CPU本機寄存器大小的變量實際上可能導致發出更多的代碼。
正如另一張海報說，不要擔心微觀優化。如果您有性能問題，請使用第一個配置文件。 10次中的9次你的性能問題不會在你認爲的那個地方。
不，我不認爲你是愚蠢的，這是一個很好的問題！
我認爲使用強類型變量是一種最佳做法。在你的例子中，變量i總是正數，所以它可能是unsigned int。
當開發程序時，我們需要考慮：1）大小2）速度和3）程序員的成本。這些並不相互排斥，有時我們會根據速度進行交易，當然，那些能夠做到這一點的人（優秀程序員）的成本要高於初學者。
還記得計算機X上什麼是最快的可能是在計算機B上較慢。它是一個16位，32位，64位等操作系統？在很多情況下，我們希望變量在字邊界上對齊以獲得速度，因此使用小於一個字的變量最終不會節省任何空間。
因此，它不是必要最好使用盡可能最小的變量，但它始終是最佳做法，作出最佳的使用類型的最佳做法。
像循環索引這樣的局部變量很便宜。一次你會有多少幀？五十？一百？一千？使用一千個int個計數器而不是一千個byte個計數器的開銷是多少？ 3K？事實證明，其中的幾個數組需要超過255個元素，節省3K是否值得返工？
如果你正在分配數以千萬計的這些東西，那麼擠壓位數可能是有道理的。對於當地人來說，這是一種虛假的經濟。
另一個因素是這種類型與你的讀者溝通。無論是好還是壞，人們對於int的解釋都很少;但是當他們看到一個byte時，他們傾向於將其解釋爲特定於字節的事物，例如來自流的二進制數據，可能是像素，或需要通過編碼器運行的流才能將其轉換爲字符串。使用一個字節作爲循環計數器會讓你的代碼中的許多讀者停下腳步，因爲他們停下來想，「等等，爲什麼這是一個字節而不是int？」
考慮這個照會可以幫助你：
運行時優化性能的32位整數類型的 （的Int32和 UInt32的），所以使用這些類型 櫃檯等經常訪問的 積分變量。對於浮點運算 ，Double是最有效的類型 ，因爲這些操作通過硬件進行了優化。
注：我認爲這是用於x86計算機OK，但對於64位我不知道。
絕對不是愚蠢的，好奇心幫助建立一個更好的程序員。 – ChaosPandion 2010-03-16 02:55:15