1樓：
C這些明顯就是「為了讓人類寫彙編」的特性其實沒啥，值得吐槽的是方程一樣的型別宣告……而且 C 偏偏是乙個沒啥抽象的語言，需要抽象的地方只好函式指標和void*滿天飛，這就讓型別宣告的問題更加明顯了……
2樓：SuperFashi
我覺得也是設計缺陷，至少不現代。而且C/C++的switch還只能搞int型別，感覺很吃屎。
感覺可以做乙個小爬蟲爬一下github上用switch case的時候寫了break的佔所有case的多少，感覺這個比例還是挺高的。
Golang的switch-case個人感覺設計很好，至少在很多短流程判斷中讓我不想寫if而是switch了。
3樓：Test
應該不算缺陷吧算語言特性，而且有時候這個特性還很有用，用一門需要必須遵守它的約定，這是基本要求。 另外寫兩千條case一定是不具備基本的程式設計思維
4樓：Mark
是設計缺陷，但是確實是當時的設計思想造就。
你完全可以說是當時的設計思想有問題，但是對於這麼早之前的設計思想，這點失誤，理應諒解。
這樣我想起了遺留系統，維護遺留系統確實很難，但是遺留系統確實有他的存在合理之處
5樓：chemoor
c 中，不認為是缺陷。
在我看來，switch 是用來加速的。
c的許多應用場景要求效率，
switch 速度比 if else 快而且在多case情況下條理更清晰。
曾經在做微控制器時，專門去掉個別 case 的 break 語句來優化尺寸。
6樓：神秘的什錦飯
因為 case 是一種 label-statement ，也就是與 goto 的目標是同一類的。在西加加的文件中，case、default 和普通的跳轉目標是放一起的：
因為都是 label，都是普通語句（不像花括號能生出 compound-statement），所以是同屬乙個 scope ，所以也會貫穿吧。
另：在西加加文件中，break、goto、continue、return 也是放一起的
又：bash 中有 case 與 esac 這一對 ，你得在其中每個分支開始時寫個右括號，在分支結束時寫兩個分號 Σ(Д)
7樓：靈劍
是，比如說Python裡根本就沒有switch，它覺得有if足夠了……switch case可讀性、可維護性都很差。break只是其中的乙個問題而已。
話說2000行的switch case你們怎麼維護得下去的，去學一下怎麼把它改成外部配置檔案或者改成多型的類。你們這麼玩下去什麼語言都救不了你們。
8樓：布客飛龍
是設計缺陷。
如果需要fall-through，不用完全取消，設計成非預設的就行了。比如加上某個關鍵字就貫穿，什麼都不加就break。
因為貫穿的情況寫 100 次也碰不到一次，不經常使用的東西，應該設計得繁瑣。可能以現在的眼光來看，它就是設計缺陷，當時誰知道這些東西。
9樓：成之六
在 C 語言中是缺陷。
《C專家程式設計》中第二章 "這不是bug，而是語言特性" 中提到: "分析程式語言缺陷的一種方法就是把所有的缺陷歸於三類:不該做的做了；該做的沒做；該做但做的不合適。
為方便起見，我們分別把它們稱作『多做之過』、『少做之過』、『誤做之過』 "。
文中 2.2 節詳細闡述"多做之過"時將 switch 語句、相鄰字串常量的自動連線以及預設全域性範圍作為案例闡述的，題主可前去研究。
我貼兩張截圖(手機答題，截圖可能略模糊對此表示歉意，過兩天補充高畫質圖):
10樓：gkmail
不是缺陷，是特性。c的switch case就是跳轉表。基於這個特性可以實現優化，這是其他語言分支語法無法實現的。
對於你的情況，我建議是將case break塊定義成巨集，這樣避免出錯，看起來也更清晰。
11樓：Runtian Zhou
因為C的設計最早只是為了簡化組合語言啊，所以在設計C的時候更多考慮的是和彙編語義的一一對應。switch本身對應的就是彙編的跳轉表嘛，編譯出來的結果就只是查表加跳轉，自然就不會考慮結束後跳到結尾的功能了。所以這個更多是乙個歷史遺留問題，然後這個遺留問題又被別的語言繼承過去罷了。
想要最正宗的switch case，為什麼不學ML Family呢【逃
12樓：王贇 Maigo
我認為是設計缺陷。
當然，設計者這麼設計是經過了深思熟慮的。但不幸的是，他設計出的結果跟一般人的思維方式不一樣，在一般人看來就是缺陷。類似的例子還有「解方程」式的 typedef。
switch case 的 fall-through 特性在個別時候使用起來比較方便，但我覺得在非個別時候忘記寫 break 造成的麻煩更大，總體來說 fall-through 是個弊大於利的特性。
13樓：
有個回答很在理 lz你應該稍微抽象下不要再這樣用case了。沒有做過RPG，不過應該沒差吧。
Swift的case語句自動兜底、除非強制fallthrough。
14樓：chunquedong
這可能真的是C的設計缺陷。
自動break是可以的，我用的fantom語言就是自動break的，暫時沒有發現有什麼缺陷: http://
fantom.org/doc/docLang/Statements#switch
。我也經常犯忘記break的錯誤，這可能是個普遍問題。而這本來從語言層面是可以避免的。C的switch語句是按照goto語句的樣子設計的，所以才會有這個問題。
作用域問題不是重點，加花括號就能解決。
15樓：十六夜砕月
先說結論:並不是，這是乙個特性。
舉個栗子，比如更新軟體時如果要同時更新使用者本地的資料庫，就可以這樣寫。
switch(ver)
這樣就能很方便的進行跨版本增量更新
16樓：杜經緯
題主想要表達的是臨時變數名不可重複吧。
這是作用域的問題。
一層大括號，一層作用域。
如果你是要各個case之間變數名可重複的話，其實很簡單：
加括號。
switch(sth)
break;
case 2:
break;
······}
為什麼每乙個日出都值得歌頌？
熊溜溜 對於我來說，白天就是希望吧。現在是大三普通本科在校學生，臨睡前總是希望明天快一點來的。晚上的時候容易胡思亂想，過去的事，以後的出路，或者過幾天的末考，希望太陽公升起讓我可以繼續投入到一天的工作裡，忽略掉自己這些胡思亂想。白天對我來說是真實的，我可以去實現我想要實現的東西的中介，而日出是一天的...
是否可以對每乙個問題和回答都加乙個「水」的投票呢？
劍秋 沒必要。王琛從 Timeline 的角度講了，我想從對待水問題和水答案的角度講。對待水問題，最重要的是讓大家將水問題改好，而不是消滅它。知乎一直以來不也是信奉著這個的麼？http www.為此，必須讓 編輯 變得更慎重。問題提出來之後，不讓使用者能直接修改問題。也不用對問題投票 這樣可能會傷害...
為什麼每乙個人都是被生活所迫每乙個人都生活的那麼的不容易
平靜的喜悅 生活就是每一天在活動再變化，你不可預知明天將發生什麼又有什麼變數，所以每乙個人都在和生活演繹著一出出喜劇和鬧劇，遇到喜劇就覺得人生多麼美好，遇到生活所迫的鬧劇，我們會努力拼搏，雖然過程不易但只要努力總會多少有意外驚喜 我們都是奔跑的追夢人！生活不易也要繼續前行，享受奔跑的那種雖累但全身放...