Debugging

透過瀏覽器的開發者工具調試 JavaScript 的方法 調試是程序設計師必備的核心技能之一。 有時候即使我們盡了最大的努力，但程序還是不能正確運行，比如說它崩潰了、運行緩慢或打印了錯誤信息。 當你編寫的程序不能按照期望的方式運行時，你該怎麼辦呢？ 你需要開始調試。 找出問題可能出在哪裡 第一步總是觀察發生了什麼，並試圖確定問題的根源所在。這是環境問題？是你給程序提供的輸入有問題？它是由於內存使用過多而導致一次性崩潰？還是每次運行都出現這個問題？ 在確定問題出自何處之後，你可以開始檢查具體的代碼部分。 閱讀代碼 在調試方面，最簡單的方法之一就是閱讀你自己編寫的代碼。用聲音朗讀。我們自己的聲音有一種神奇的作用，但無法在靜音時產生。 很多時候我都是通過這種方式找出問題所在的。 使用控制台 如果閱讀代碼沒有給你任何提示，下一個合理的步驟就是在你的代碼中添加一些可以提供一些線索的行。 在 JavaScript 前端代碼中，你通常會使用 alert() 和 console.log （和它的其他應用）。 考慮以下代碼： const a = calculateA() const b = calculateB() const result = a + b 結果不正確計算，所以你可以在計算結果之前添加 alert(a) 和 alert(b)，當代碼執行時瀏覽器將彈出兩個警告窗口。 const a = calculateA() const b = calculateB() alert(a) alert(b) const result = a + b 如果傳給 alert() 的是一個字符串或一個數字，這樣操作是沒有問題的。但一旦涉及到數組或對象等較復雜的數據類型，使用 alert() 就會變得很困難了，這時候你需要使用控制台 API。我們可以先從 console.log() 開始： const a = calculateA() const b = calculateB() console....

在給用戶提供反饋的同時，有時也可以用來協助調試應用程序，最常見的方式之一就是使用警告訊息。 SwiftUI 提供了 .alert() 修飾符，我們可以根據某些條件來顯示警告。 讓我們從以下範例開始，其中有一個帶有計數器的 Button： import SwiftUI struct ContentView: View { @State var count = 0 var body: some View { Button("Count: \(count)") { self.count += 1 } .font(.title) } } 當 count 達到 10 時，我希望顯示一個警告訊息。 我們該如何做到這一點？ 我可以在 ContentView 中添加一個名為 showAlert 的布爾屬性，並編輯 Button 的點按操作內容： struct ContentView: View { @State var count = 0 @State var showAlert = false var body: some View { Button("Count: \(count)") { self.count += 1 if self....

我最喜欢的代码编辑器是来自微软的 VS Code。在过去的20年里，我使用过许多编辑器，但这是迄今为止最好的。 VS Code 是开源的，即使在我的不太新的 MacBook Pro 上也很快，它从不在进行中崩溃，它可以自定义扩展，但开箱即用效果也很好。 这一切都很棒，但是如何调试 Go 程序呢？你可能认为需要一个笨重的 IDE，但事实并非如此。通过 Delve，由 Derek Parker 开发的工具，调试 Go 程序非常简单。 首先，当然，你需要安装官方的 Go VS Code 扩展，并且确保已配置好 $GOPATH。 安装完成后，在 Linux/Windows 上，你只需要执行命令 Go: Install/Update Tools。在 Mac 上，你需要通过 Brew 下载 Delve，只需要在你喜欢的 Shell（应该是 zsh）中键入 brew install go-delve/delve/delve - 文档中提到了自签名，但 Brew 会替你处理这个问题。 完成后，设置调试器配置。 点击 VS Code 的 调试菜单，点击“开始调试”，或者按下 F5 键。 VS Code 将调试信息放在工作区根目录下的 .vscode/launch.json 文件中。这个文件将会自动生成，并且应该能够直接用于本地调试： { "version": "0.2.0", "configurations": [ { "name": "Launch", "type": "go", "request": "launch", "mode": "debug", "remotePath": "", "port": 2345, "host": "127....

每個瀏覽器都提供了一個控制台，讓您可以與 Web 平台 API 進行交互，並通過打印由網頁中運行的 JavaScript 代碼生成的消息來查看代碼的內部結構。 控制台概述 使用控制台日誌格式化 清除控制台 計算元素的數量 記錄複雜對象 記錄不同級別的錯誤 在導航期間保留日誌 分組控制台消息 打印堆棧跟踪 計算所花費的時間 生成 CPU 配置文件 控制台概述 控制台工具欄很簡單。有一個按鈕可以清除控制台消息，您還可以在 macOS 上單擊 cmd-K ，或在 Windows 上單擊 ctrl-K 以清除控制台消息，第二個按鈕可以激活一個側邊欄，讓您可以按照文本或消息類型進行過濾，例如錯誤、警告、信息、日誌或調試消息。 您還可以選擇隱藏網絡生成的消息，只關注 JavaScript 日誌消息。 控制台不僅是您可以查看消息的地方，還是與 JavaScript 代碼和 DOM 進行交互的最佳方式，並且有許多時候還用於從頁面上獲取信息。 讓我們輸入我們的第一條消息。請注意 > ，讓我們在此處點擊並輸入 console.log('test') 控制台充當了一個 REPL（Read-Eval-Print-Loop） ，這意味著它解釋我們的 JavaScript 代碼並打印一些東西。 使用控制台日誌格式化 正如您所見，console.log('test') 在控制台中打印了 ’test’。 在您的 JavaScript 代碼中使用 console.log 可以幫助您調試，例如打印靜態字符串，但您還可以將變量作為參數傳遞給它，該變量可以是 JavaScript 原生類型（例如整數）或對象。 您可以將多個變量傳遞給 console.log ，例如： console.log('test1', 'test2') 您還可以通過傳遞變量和格式指定符來格式化漂亮的短語。 例如： console.log('我的 %s 有 %d 歲', '貓', 2) %s 將變量格式化為字符串 %d 或 %i 將變量格式化為整數 %f 將變量格式化為浮點數 %o 用於打印 DOM 元素 %O 用於打印對象表示形式 示例：...

如何在使用Git跟踪長期的變更歷史時排除幾乎所有涉及到的問題，並發現你在代碼中引入的錯誤。 有時我們會長時間地在項目上工作。我們可能會精心製作出一個完美的1.0版本，然後將其發布給公眾，然後我們開始進行錯誤修復，之後我們會收到功能要求並努力改進應用程序。 在此過程中，您發現了一個回歸錯誤：這是由代碼中的非相關更改引起的意外問題。 某些內容沒有按照預期工作，即使您最近並沒有真的更改過該部分的代碼。 或者您經常接觸某個文件或函數，以至於您無法記住哪個更改可能引起了向您報告的問題。 在任何情況下，首先要做的是確定錯誤所在。 如果您使用的是像Git這樣的版本控制系統，事情就變得容易了。您可以回到過去，找出引入該更改的確切提交。在團隊合作時，這非常重要，因為有其他人可能已經處理過這個問題，如果他們導致了錯誤，您可能不知道該怎麼辦 - 除了請他們去修復它，因為Git可以提供這些信息。 一種方法是手動檢出某個特定的提交。例如，您可以檢查昨天的代碼版本是否正常工作。 我使用 GitHub Desktop，這是由GitHub開發的一個很棒的Git客戶端。它非常適合日常使用，但無法讓我檢出單個提交。其他一些客戶端可以，但您可以使用命令行。 運行以下命令： git checkout <COMMIT_SHA> 其中，<COMMIT_SHA>是您想要回溯的提交，它看起來會像 5a06d3ca5e7adb6e67。 如果您仍然遇到問題，您可以尝试使用前一天的另一個提交進行同樣的操作，依此類推，直到找到一個代碼運行正常的提交。 現在，您需要應用“分而治之”的原則，在您嘗試且未發現問題的最後一次提交和運行正常的提交之間選擇一個提交。 重複這個過程，每次將提交的範圍縮小一半，直到找到引入問題的提交。 這是一個常見且實用的方法，Git引入了bisect命令來自動化這個過程。 從最新的提交開始。使用git checkout 您的分支名，例如 git checkout master（如果您已經檢出了較早的提交）。 然後運行以下命令： git bisect start 目前還沒有發生任何事情。您需要告訴Git一個壞的提交參考，即代碼不運行的提交： git bisect bad HEAD 以及一個好的提交，即代碼運行正常的提交： git bisect good 7f4d976e7540e28c6b0 Git開始執行過程： Bisecting: 3 revisions left to test after this (roughly 2 steps) [d18ebf1c7db9a9b44e8facc5ddb3551e641a64e2] fixes #25 看到了嗎，此處的HEAD到我提到的“good”提交之間有6個提交。Git告訴我還有2個步驟，直到找到問題所在的提交。 接下來，我測試代碼，然後告訴Git結果：git bisect bad（如果失敗）或 git bisect good（如果成功）。 重複此步驟，直到找到問題所在的壞提交，然後運行 git bisect reset 返回到HEAD提交。...

在建立React應用程式時，例如使用Next.js建立的應用程式，React Developer Tools是一個絕對必要安裝的工具。 React Developer Tools提供了一個檢查React應用程式的工具，可以顯示React元件樹狀結構，並且可以查看每個元件的props、state、hooks等等。 安裝好React Developer Tools後，你可以打開瀏覽器的開發人員工具（在Chrome中，右鍵點擊頁面，然後點擊Inspect），你會發現兩個新的面板：Components（元件）和Profiler（性能分析）。 如果你將滑鼠移動到元件上，瀏覽器會在頁面上選擇由該元件渲染的部分。如果你在樹狀結構中選擇任何元件，右側的面板將顯示對應元件的父元件和傳遞給它的props： 你可以輕鬆地通過點擊元件名稱來進行導航。 你可以點擊開發人員工具工具欄中的眼睛圖標來檢查DOM元素，如果你使用第一個圖標（方便地位於類似常規DevTools圖標下方的滑鼠圖標），你可以將滑鼠懸停在瀏覽器UI中的元素上，以直接選擇渲染該元素的React元件。 你可以使用bug圖標將元件數據記錄到控制台。 這非常棒，因為一旦你將數據打印出來，在控制台中你可以右鍵點擊任何元素，然後選擇“存儲為全局變量”。例如，我在此示例中使用了url prop，並且我能夠在控制台中通過臨時變量temp1來檢查它： 使用Next.js自動加載的Source Maps（在開發模式下），從元件面板中，我們可以點擊<>代碼，DevTools會切換到Source面板，並顯示元件的源代碼： Profiler（性能分析）標籤更加出色，如果可能的話。它允許我們記錄應用程式中的交互並查看發生了什麼。我現在還無法展示一個例子，因為至少需要兩個元件來創建一個交互。我稍後會談到這個。 我展示的所有截圖都是使用Chrome，但是React Developer Tools在Firefox中的工作方式是相同的：

一篇關於如何禁用 ESLint 規則的快速教程 您的工具可能會自動設置no-debugger和no-console規則，但您可以做些什麼來禁用它們呢？ 在開發模式中，瀏覽器調試工具和Console API的訪問是必不可少的，雖然在生產代碼中可能有正當的理由禁用它們。 您可以通過添加如下幾行代碼來禁用一個或多個特定的ESLint規則： /* eslint-disable no-debugger, no-console */ console.log('test') 或者您可以在一個區塊中禁用它，在之後重新啟用： /* eslint-disable no-debugger, no-console */ console.log('test') /* eslint-enable no-alert, no-console */ 或者您可以在特定的行中禁用該規則： console.log('test') // eslint-disable-line no-console debugger // eslint-disable-line no-debugger alert('test') // eslint-disable-line no-alert 另一種方法是在項目全局禁用該規則。 在package.json中，您可以找到eslintConfig規則，裡面可能已經有一些內容，像這樣： "eslintConfig": { "extends": [ "react-app", "react-app/jest" ] }, 在這裡，您可以禁用您想禁用的規則： "eslintConfig": { "extends": [ "react-app", "react-app/jest" ], "rules": { "no-unused-vars": "off" } },

以下是我在 PHP 調試中常用的一段程式碼。 我想要將值使用 error_log() 印出到 error log 中，但是它只接受字串作為輸入。 因此，我使用以下程式碼片段將 var_dump() 的結果印出： ob_start(); var_dump($something); $contents = ob_get_contents(); ob_end_clean(); error_log($contents);