goto用不好，就說goto有問題，我勸一些程序員認清自身問題先！

公司有個程序員小哥，在使用Modbus RTU做數據通訊，往設備寄存器里面寫入數據，因為是半雙工，且一個串口上面連了好幾個設備，所以Modbus RTU在寫入數據時可能會出現超時和寫入失敗的情況，我就告訴他，在寫入數據前面先定一個錨點標簽，如果寫入失敗，則直接goto 回錨點那里再次嘗試寫入，為了避免死循環，增加一個計數變量，如果連續寫入失敗10次，才正式返回寫入失敗的結果給前端。

程序員還知道跟我說goto返回錨點不能亂用，我跟他說，goto本身沒什么錯，之所以有隱患，是因為用的人不能善用它導致的，只要你控制好出口，那就不會出什么大問題，小哥將信將疑的就去改代碼了！

過了一會兒，他跑過來告訴我：“哥，用了goto以后軟件直接假死了！”

我聽他說這話就來勁了：“什么叫用了goto以后軟件假死？”

其實，我聽他說軟件假死，我就知道肯定是因為他代碼寫錯了，沒有控制好goto的出口，所以代碼直接死循環了，我也好奇他是怎么把goto給弄成死循環的，所以就來到他的工位上看了下他的代碼。

看完給我整笑了，我一眼就看出了問題所在！

他雖然按我說的，對goto次數進行了判斷，但是他的計數變量卻放在了錨點之后，也就是說每次goto回錨點以后，這個計數變量雖然之前都被賦值了，可是goto之后的新代碼空間里，這個計數變量又被重新初始化了！

于是，我就把道理跟他講，還批評他，這個問題只要稍微下個斷點調試下就能發現。而他不光沒有反省自身問題，反而又把問題拋給了goto，說goto還是不能亂用！

聽到這話，我腦袋都要撓禿嚕皮了，我問他，這種情況下，他不用goto用什么？

他回答：“遞歸、while循環、計時器、線程等待都可以！”

我跟他說，雖然解決方法有很多，但是像遞歸、while循環監聽狀態本身隱患就不比goto少，而計時器和線程等待多多少少都會出現阻塞線程或者增加不穩定因素，最重要的是，相比這三種方法，goto的語法更為簡潔，理解起來也更加容易。

盡管我這么說，他還是有點不服，不服就不服吧，我最后跟他說：“代碼從來都沒有固定的書寫方法，用什么方法比較好，我覺得看你自己，你如果覺得goto不好用，那你就用你自己的方法去做！但是對于我來說，我覺得goto挺好用的！”