求出 2 個數字中的較大值

我覺得第一種**在設計模式方面會更清晰，可重用性也不錯，也許這個問題看起來更小，所以你覺得第二種方式是直觀和精簡的;

但是，在大型專案中，您會考慮什麼？ 比如我上乙份工作，光是我做的乙個模組就有幾十萬行**，如果不標準化，會是什麼樣子？

1.比如說，為了實現你的比較函式，大家編寫程式並使用它，那麼為什麼不做乙個函式，到時候大家直接呼叫呢？ 在我的專案中，連鍊表和樹都是封裝的，使用時可以呼叫，這樣就不用每次使用都寫，整體上是很大的簡化;

2.如果每次都自己寫，每個程式設計師可能都有不同的思維方式，可能由窮人級別編寫的程式可能會引入bug，這意味著每一次開發或維護都會增加風險，而牛X的程式設計師可能也有寫出精華的好方法，但普通人不容易理解， 所以維護的時候是很大的，尤其是修改別人的程式的時候（一般在2000行左右），如果結構不清晰，是不是看起來特別費時間？

你所謂的簡單，只是寫作的簡單，在實際程式設計中主要有兩點考慮：

時間複雜度，空間複雜性。

這就是為什麼我們主要關心應用程式占用多少臨時儲存空間以及花費多少時間的原因。

從這兩個方面來看，這兩種演算法的複雜度處於同一數量級，因此複雜度相同。

但是，從程式的可復用性、可移植性和可讀性的角度來看，第乙個顯然更好，比如這裡要找2個大數，如果是3個數字，如果是找小數，就把子模組中的**改寫一下就行了。

因此，在編寫程式時，**的複雜和簡單只是乙個方面，應該從整體上考慮。

從任何角度來看，您給出的兩個例子都是第二個例子。 在實際使用中，也使用了第二個示例。 （初級程式設計師編制的**除外）。 只要使用它，完全沒有問題。

一般來說，程式設計應該避免晦澀難懂的**，但第二個例子不包括在內，“？”。運算子是標準C語言的基礎，不存在任何合格的C程式設計師都無法理解的問題。 看第乙個例子，有一種羅里囉嗦的感覺，不夠簡潔。

就我個人而言，我認為編寫第乙個示例的程式設計師是不專業的。

至於你說的：“書中推薦第一種方法”，大概第乙個例子是為了教學目的，我從來沒有見過一本書建議不要使用第二種方法。

您如何看待程式設計的目的？

當然，程式設計是關於解決現實世界的問題。

程式設計只是軟體工程的一小部分，約佔 20% 的時間。 為什麼？

這是因為現實中的問題非常複雜，如果要將它們翻譯成計算機以便能夠理解它們，那麼複雜的事情就必須簡化。

使用函式是降低複雜性的一種方法。 這就是書籍推薦使用函式的原因。

當然，如果你剛開始學習程式設計，你可能不明白以下內容）降低複雜性。

避免重複**段落。

限制更改的影響。

隱式順序。 改進了效能。

實施集中控制。

隱式資料結構。

隱式指標操作。

隱式全域性變數。

段重用。

計畫開發乙個軟體系列。

提高某個段落的可讀性。

提高便攜性。

分離複雜的操作。

使用獨立的非標準語言功能。

簡化複雜的布林測試。

祝你好運。 呵呵。

a>b? a:b;表達。

下次比較 c 和 d 時，必須重新編寫。

比較 e、f，你會再寫一遍。

比較陣列元素並再次寫入 n 次。

以函式的形式，可以重複呼叫。

如果只是 a、b 的匹配，那就沒關係了。

就我個人而言，我認為。 對於大多數普通的初學者程式設計師。

第一種方法更好。

不過有很多說法。 但這很容易理解。

一步一步地，很清楚。

而第二種，容易讓人迷惑。

只有打下深厚的基礎，才能簡化程式。

簡單地說。 這兩種方法在少於 100 行的程式中很方便。

但是當程式達到幾萬行時，第二種方法就不容易閱讀和修改了。

如果你使用乙個函式，乙個比較通用，比如第二種寫變數的方式叫c和d，你要重新改一下，第二點是可以復用，不需要每次都寫同樣的語句，減少**的數量，你可以用巨集來代替。

第一種“解釋”語法比較詳細，適合初學者掌握更多的知識點，而第二種方法顯然是在實際操作中提煉出來的簡單實用的方法，這個技能一般需要個人在不斷的程式設計實踐中總結出來。

僅就這兩個程式而言，哪乙個更簡單並不重要。

推薦第一種選擇的人主要希望程式設計師養成更好的功能模組化習慣。

通過呼叫函式的方法，更符合編寫程式的規範。

這意味著當 b > a 時，b 的值被賦值給 a，a 不再是 a 的值，而是 b 的值，如果是 b >，那麼 a 仍然是 a 的值，也就是說，a 的值是 a 和 b 變數中較大的值。

同理，當c>a時，c的值被賦值給a，a不再是a的值，而是c的值，如果a>c那麼a仍然是a的值，也就是說，a的值是a和c變數的值。

即先取出a和b中的最大值，然後將最大值與c進行比較，再取出它們之間的最大值（最大值為變數a）。