這倆算是基礎吧，不會用的人可以去當產品了！

還有就是有的語言是沒有這倆關鍵字的！

遇到不會用遞迴的程式設計師倒是不少

誰說不用的。關鍵是這樣的需求不是很多。break經常用，continue用得少，但不代表不用，只是需求很少有而已，本人用過，

在迴圈體內，break肯定是經常使用的，找到了我需要的資料後，就不再繼續往後執行迴圈了，就使用break跳出迴圈，提高了執行效率，也對執行結果的正確性有影響，結果可能不是想要的值。

continue的作用就是也是減少後續語句的執行，跳到下個迴圈變數再繼續執行，也是提高執行的效率，對程式的結果通常無影響。如果不考慮程式的可讀性，當然可以利用很多的if巢狀實現相同的效果。

是否寫break,continue，迴圈次數少的，影響不大，如果迴圈次數多的，判斷條件多的，且查詢的結果比較靠後，對效率影響巨大。這2個用不好，可以說不是一個合格的開發人員。

上述僅僅針對c語音，其他語言沒寫過，理論上也是一樣。

經常用啊。如果沒用過只能說明不會用，或者寫的程式碼還太少。迴圈中做一件事情，目的達到了，還有必要繼續執行迴圈嗎？這時候直接退出break就行了;迴圈中判斷條件是否成立，如果成立才繼續做某件事情，如果不成立，繼續下次迴圈，這時候就用continue。沒用過，說明還沒有入行程式設計師。

沒有人從來不用的。別說break和continue這麼常見，就是goto，也只是建議儘量少用，不是禁用。如果某個語句真有禁用的充分理由，語言本身就取消它了。語言設定了這條語句，就有使用的情景，機會少你沒遇見而已。

break和continue，適當的寫法是可以不顯式寫出來，比如透過賦值使迴圈條件滿足而自動結束，但並非總能如此。只要閱讀起來邏輯順暢、簡潔，就用。沒有什麼是一定的，嶽不群教徒弟只會誤人子弟。

要提高效率，break和continue應該是經常會用到，從我觀察過的程式碼的經驗來看，有的偏向業務程式設計，即保證正常用就行，還有就是結構化程式設計，，這種往往就會考慮模組複用，演算法效率等問題，在這種程式設計風格當中，你會發現return，break，continue會經常出現，哪怕能提高一丁點的效率，這在我看來也是有益處的

很多人都從語法層面去想，那肯定是很難理解的，畢竟存在就是合理，如果這兩個東西有問題，就不會出現。 有公司禁止，主要是要降低專案複雜性，一個團隊有高手有菜鳥，還有人員流轉問題，還有後期維護問題，一個函式如果有巢狀幾個迴圈各種break continue ，你寫的時候可能覺得沒問題，但接手的人可能要分析半天，還容易出錯。 不能只從自己的角度去分析一個問題的合理性

從來都不用，只能說明你的經驗不夠豐富，從事開發的業務過於有限，從未站在更高的角度去思考問題，以至於不需要使用。如果你一輩子不使用，那水平估計也就這樣了。

continue，是跳過迴圈體內部分語句，這個跳過肯定是有條件的（如果是無條件跳過，那被跳過的語句寫了幹嘛），因此可以用if代替。

break，直接跳出迴圈。這個還是挺常用的。從結構化程式設計原則來說，它違反了此原則。但是，若不用break，我們就要設定代表迴圈結束的bool變數，並在迴圈條件中加以判斷，這降低了程式碼可讀性。雖然說break違反結構化程式設計原則，可是，結構化程式設計的目的，不就是增強程式碼可讀性、可維護性嗎？使用break的程式碼，反而比不使用的可讀性更高。

我很多同事，開發上十年了，看他們寫的程式碼，if巢狀9層以上了，都不用一個continue，看他們程式碼好累好累啊，真不知道上十年怎麼混過來的[捂臉]

問這個問題的人，你懂程式設計和演算法嗎？

寫程式，肯定是在實現功能的情況下，如果不損失效能或者損失的效能在合理範圍內，肯定是要讓程式碼易懂，好維護，這樣的前提下，你說我為啥要用break和continue呢？

仔細回憶了一下，很多時候，都喜歡while 1迴圈，然後，if break，這樣，其實邏輯理解上來好像是最簡單的。continue，好像確實不多~~~

怎麼可能不用。不用只能說明是最初級的那種API boy，直接拿到就調庫，深入進去的演算法流程都從來無需考慮，也從來未曾考慮過。

我印象中一些書籍中說continue，goto之類的語句容易產生錯誤，建議儘量不要使用。這句話倒也沒什麼錯誤。其實不管什麼語句，不能非常清晰的明白用法，然後在程式中清晰的用出來都是容易出錯的。但是存在就是有道理的，如果這個真的不能用的話，為什麼會存在呢。只要理解透徹，思路清晰，有什麼不能用的。那些絕對不使用goto的，可能太教條了，看到書裡這麼寫就從來沒去了解過。

話說break，continue應該是常用的吧？break不用。。。我感覺就不能沒法寫程式了吧？continue用的少，但是也算常用語法吧

1、剛開始程式設計的，break，continue，不分場合使用。這裡的心態是不用程式就寫不下去了，不得不用。

2、1-3年的，能少用少用，而且影響程式可讀性，可以用其他語法代替。這裡的心態是是能不用就不用。

3、成熟的開發者，該用的時候用，只是應用場景很少，大多在效能最佳化等方面，正常的情況根本用不到。這裡的心態是該用就用，只是該用的場景很少。

大部分程式設計師是寫業務邏輯，不是寫演算法，break和continue是流程控制語句中用來控制流程的出現在for while switch-case，業務邏輯一般都是順溜而下，用if else更多

這兩語句我經常用，你不用是你不會用，不等於大家不用。

舉個簡單應用例子，例如，遍歷一個列表陣列，如果要很多判斷找元素，當初判斷不適合時可用continue，不必做多餘計算，而當找到想要的元素時可以break跳出迴圈。

當然，還有其他用法，總之，這兩語句還是很好用。

很多公司的程式設計規範都沒有對break和continue的使用做限制，真實生產環境下對這兩者的使用頻率還是蠻高的，在正確使用的情況下，是能夠提高程式碼效率和程式碼可度性的。不推薦使用的關鍵字是goto，過多使用goto會影響程式碼可讀性，邏輯複雜時，也不利於程式碼可維護性。

嵌入式產品高階狗一枚。確實不用。我寧願你return 0，也不想讓你break，跳來跳去的，回頭自己都不知道跳哪去了。。雖然說語法沒錯，但實在不是個好習慣

我覺得問題應該改下，哪些型別的程式設計師不用常用、或者不用break或者continue關鍵字？

進入正題，我分如下幾點分析下：

一.不用或者不常用break或者continue關鍵字：

1.用匯編語言的程式程式設計師，（好像）沒有這兩個關鍵字，都是用“J”字母開頭的指令跳轉，例如JMP。

2.演算法牛逼的程式設計師。

3.熟悉自己所用程式語言封裝的各種查詢方法的程式設計師。

二.常用break或者continue關鍵字：

1.剛入門的程式設計師。

2.不熟悉各種快捷查詢的程式設計師。

3.喜歡用簡單粗暴方法解決問題的程式設計師，沒有迴圈解決不了的，哈哈。

總結：

個人覺得，在沒有很好解決辦法時，break、continue是迴圈體內很好的解決辦法。

取到自己想要的資料後break掉迴圈，減少迴圈次數，提高效率。過濾自己不想要的數 據，continue直接跳出本次迴圈，執行下一次迴圈。