-
1 # 二妹的二哥哥
-
2 # 達達尼爾央
你對語言的安全規範瞭解嗎?例如四則運算的安全規範知道嗎?你英語尚可嗎?你知道sonar,findbugs等程式碼質量工具嗎?你知道本地的ide配置可能和別人的不一樣,會發生你本地都是0,別人的ide裡到處是warn嗎?你知道自動化構建工具鏈可能在異構的系統中,可能和你本地編譯環境不一樣導致有些新的語言特性不相容嗎?你知道沒有ut覆蓋的程式碼是不安全的嗎?你知道為了能配合ut,你的程式碼可能要修改很對地方嗎?你的2000行程式碼有每一次完整的提交記錄嗎?每次提交的commit msg和實際提交內容符合嗎?每次的提交是slim的嗎?每次提交沒有多餘的不相關的程式碼嗎?你是否經常會使用一些語法技巧而忽略可讀性,是否會覺得別人讀不懂你的程式碼那是別人技術不行?你是否會寫三元條件表示式?以上還僅僅是工作流程方面的,語言語法還沒說因為不知道你用什麼語言,專案實施你沒問所以不知你有沒有什麼概念,你只關注自己2000行程式碼就如何如何,不知你是否長期一個人獨當一面,也算是大拿了……
-
3 # wdfzzy
這有點像是外行的問題。只注意了數量,忽略了質量,內容。有些程式程式和複製貼上差不多,不出問題難度不算大。有的程式可能關鍵的幾行就得反覆除錯優化。
-
4 # 土豆泥巴水
沒人這麼寫程式碼的,都是寫幾行就要編譯測試下,當然你要是拷自己原來測試過的程式,問題不大,2000行算不上啥多大程式,正常人是不會寫很多再編譯,都是寫一個小程式,或一個小函式就編譯測試,然後一個一個累加,最後完成要的功能,不然當中有錯會查死人的
-
5 # 晴月浩新雪
第一,編譯器能有機會報出來的錯誤恐怕是程式設計師最容易除錯的錯誤了。對於合格的程式設計師,零編譯錯誤大概最多隻能證明你的打字不錯。
第二,現在稍微有點質量控制的專案開發都會啟用各種build cop在編譯階段增加靜態程式碼質量檢查。程式碼編譯器不報錯,或許只證明你打字不錯,真正做到讓靜態程式碼分析器(全規則檢查時)不報錯,才或多或少說明你有點“經驗”。但同樣只是個入門基礎,不值一提!
程式設計師的工作,遠遠多於和編譯器還有靜態程式碼檢查打交道的的那點玩意,還是不要只盯著那些幾乎可以看成labor work的打字賣油翁的指標,把精力放在真正有意義的有獨特價值和智力參與的事情上吧。
-
6 # 散居獵人
毫無意義。
模組化開發,不太可能一下子寫2000行。
如果真有人這麼做,要麼是貼上拷貝簡單改引數,要麼不懂程式碼重用和優化。
有語法錯誤都是正常的,軟體開發靠演算法模型,看效能,程式碼著重可讀性可重用性,不是壘磚頭砌牆。
-
7 # 十年1覺
error 只是編繹通不過,不是什麼問題,比如語法錯了,打錯字詞了,多了少了個符號等,排查起來也方便,正確使用型別等,warning也不是什麼問題,bug倒難避免,除非邏輯實在簡單,不過,太簡單的邏輯註定這程式基本無用
-
8 # TrubleMake
不可能。退一步說,就是這些全過了,邏輯上有沒有問題?打個不確切的比方,高考你能門門滿分嗎?或者簡單點,你最擅長的科目滿分嗎
-
9 # zengxi129
用一個優秀的IDE,把所有IDE warning搞定,做的東西如果手熟是可以的。當然以前很多寫c的人,除錯起來很複雜,寫一天程式碼編譯一次很常見,腦補編譯是必備能力,現在把人養懶了
-
10 # 小白說程式設計
2000行程式碼一次性通過,沒有任何異常,這種情況基本很少見!
拿我們日常編碼來說,2000行的程式碼一般能實現一個小模組兒。
在程式設計師開發程式的時候,不是一次性寫2000行程式碼,然後再去編譯執行。更多的時候是每寫一個函式,甚至每寫一行程式碼,都會去編譯一次,去糾錯和優化。這樣很少能出現程式碼bug。
程式設計師寫bug是很正常的,但是都是在開發的時候就儘量減少bug的發生,所以養成一個優良的開發習慣是非常重要的。
就算開發程式中有bug存在,也是正常的。不能肯定說百分之百的軟體都有bug,但是99%的軟體都會或多或少有一些bug。但是程式設計師要認真對待bug,因為程式設計師都是在bug中提升自己。
如果能一次性寫2000行程式碼,並且沒有任何異常,說實話,這樣的人,能力很優秀,但是開發規範有待改善。
回覆列表
其實也不是很難,只是現在常見的編碼人員多使用高階語言,開發方式比較依賴編譯除錯等。程式碼寫完或寫一半,粗看一下甚至不看,直接就編譯、除錯一下,看到error,warning後逐一修改一下。
在早期,編碼過程是一個精細活兒,釋出除錯一下很花費時間與資源,執行的成功率就很重要。雖不能說每次都無缺陷,用文字工具仔細程式碼走查後,一次編譯、除錯、測試完全通過的情況,也是有一定比例的。現在有些特殊系統也有類似特點,但少很多。
這就像用上傻瓜相機,效率是很高,但也會產生一些問題:1對除錯環境有一定要求,並非所有的編碼工作都能具備快速編譯除錯的條件。2有了這個柺棍,不易養成寫前構思的習慣及寫後讀程式碼能力;不易對所用語言形成深入理解;頭腦中不能很好的對所寫程式碼,形成比較準確的想象;產出物容易隱藏一些編譯、除錯、測試等都發現不了的深層問題。當然,這麼做好處是更關注業務本身,降低了編碼難度。所以現在編碼的人多了,總水平是下降了。不過每個時代都有牛人,現在也有人肉編譯器,所以是會者不難。