您的靜態分析器已將某個條件標記為始終為假。根據您使用的工具，警告訊息可能如下所示：
- SonarQube： “始終為真或始終為假的條件表達式可能導致無法執行的程式碼” （RSPEC-2583）
- IntelliJ / Inspectopedia： “由於條件靜態評估結果為假，因此代碼未進行分析。”
- Checkmarx / Fortify： “無法存取的程式碼，偵測到死分支”
- ESLint： “無恆定條件，意外恆定條件”
- 皮林特： “W0125：使用具有常數值的條件語句”
這些都表達了同一個意思：分析器在分析時（無需執行程式碼）就已證明，條件語句中的特定分支永遠不會執行。該分支的條件始終為假。該分支內的所有內容都是死代碼。
本指南涵蓋了導致這些警告的原因、如何確定每個警告屬於哪個類別、每個類別的正確解決方法、何時應該抑制警告，以及遺留 COBOL 代碼中始終為假的條件揭示了遷移範圍的哪些信息。
靜態分析如何偵測始終為假的情況
現代靜態分析器使用符號執行和資料流分析，而非簡單的模式匹配，來偵測始終為假的條件。分析器會追蹤程式中每個變數在每一點的可能取值。當遇到條件語句時，它會根據已知的變數約束條件，評估該條件是否可能為真。
導致總是誤報的主要機制有三種：
符號執行。 分析器為變數指派符號值，並追蹤操作如何約束這些值。如果變數 x 被分配 0 在第 3 行並進行比較 x > 10 在第 7 行沒有中間賦值語句的情況下，條件顯然為假。
類型系統限制。某些條件在給定變數類型的情況下是不可能的。例如，在非空斷言之後，將非空物件參考與空值進行比較，或將枚舉值與其定義集合之外的枚舉值進行比較。
布林代數簡化。 簡化後的複合條件 false 無論變數值為何： (a && !a), (x > 10 && x < 5), (!flag || false).
SonarQube 的規則 RSPEC-2583 專門使用了符號執行：它會追蹤控制流程圖中變數的狀態，並標記出符號狀態導致條件明顯為假的情況。 IntelliJ 的「條件靜態評估為假」警告也採用了相同的方法。
四大根本原因
正確解決始終為誤報的警告取決於正確識別四個根本原因中的哪一個。針對每個根本原因，解決方法各不相同。
根本原因一：邏輯矛盾
此條件包含邏輯上的不可能，兩個不能同時為真的子條件，或一個可以簡化為下列情況的複合條件： false 通過布林代數。
Java的
// Example: mutually exclusive subconditions
int score = getScore();
if (score > 90 && score < 50) { // Always false: no integer is both > 90 and < 50
applyBonus(); // Never executes
}
// Example: boolean tautology negation
boolean active = isActive();
if (active && !active) { // Always false: a && !a = false
sendNotification(); // Never executes
}
// Example: range check already guaranteed
if (value >= 0) {
if (value < 0) { // Always false: already know value >= 0
handleNegative(); // Never executes
}
}解析度： 修正邏輯。要嘛是條件語句有拼字錯誤（開發者本意是…）。 score > 90 || score < 50或應該刪除該分支。在範圍檢查範例中，內部 if 內容冗餘，應刪除。
根本原因二：業務規則變更累積
這是長期運行的程式碼庫中最常見的原因。當初編寫時有效且有意義的條件語句，由於後續程式碼的變更而永久失效，而沒有人刪除已失效的分支。
Java的
// 2018: processType could be A, B, or C
// 2023: type C was deprecated and removed from the system
// The processType field is now guaranteed to never equal "C"
// but nobody removed the branch that handled it
public void process(String processType) {
if (processType.equals("A")) {
handleTypeA();
} else if (processType.equals("B")) {
handleTypeB();
} else if (processType.equals("C")) { // Always false since 2023
handleTypeC(); // 47 lines of dead business logic
}
}蟒蛇
# Python equivalent: accumulated rule changes
def calculate_rate(customer_tier: str) -> float:
if customer_tier == "GOLD":
return 0.05
elif customer_tier == "SILVER":
return 0.03
elif customer_tier == "BRONZE":
# BRONZE tier was eliminated in Q2 2021
# All BRONZE customers were migrated to SILVER
# This branch has been dead for 4+ years
return 0.01 # Never executes
return 0.0解決方案：驗證業務上下文，然後徹底刪除已失效的分支。實現該條件的業務規則已更改，因此不再需要實作該條件的程式碼。在提交資訊中記錄刪除操作：“已移除 BRONZE 費率分支，該層級已於 2021 年第二季度取消，所有客戶已遷移至 SILVER。”
根本原因三：面向未來的防禦性編程
有些始終為假的條件是故意的，開發人員編寫它們時就知道該條件目前不可能為真，以此作為防禦措施，防止將來程式碼更改使其為真。
Java的
// SonarQube RSPEC-2583 explicitly exempts these:
final boolean DEBUG_MODE = false;
if (DEBUG_MODE) { // Always false -- intentional
dumpDiagnostics(); // Not unreachable in intent, only in fact
}
// Type narrowing that appears redundant
String value = getValue();
if (value == null || value.isEmpty()) {
return;
}
// At this point, static analysis knows value is non-null and non-empty
if (value == null) { // Always false -- already checked above
throw new IllegalStateException(); // Defensive guard
}SonarQube RSPEC-2583 明確規定了一個例外：“當條件是單一最終布林值”或“當條件字面值為真或假時”，這些將被視為有意為之，並且不會被標記。
解決方法：如果條件是偵錯標誌或編譯時常數：保留它，並在工具標記時添加抑制註解。如果它是防禦性的空值檢查或範圍保護，雖然感覺冗餘但確實有效：重構程式碼，在其他層級明確地實現保護，或提供文件說明理由後將其抑制。
根本原因 4：運行時配置導致的工具誤報
靜態分析器無法查看執行時間配置、環境變數、反射、註解處理或依賴注入。對分析器而言始終為 false 的程式碼，可能可以透過分析器無法建模的執行時間機制存取。
Java的
// IntelliJ / Inspectopedia note: "This may cause false-positives if any kind
// of code postprocessing is used, for example, if an annotation processor
// later replaces the method body with something useful."
@ConditionalOnProperty(name = "feature.experimental", havingValue = "true")
public class ExperimentalFeature {
// This class may appear unreachable if the property is false in the
// test configuration the analyzer uses -- but it IS reachable in prod
}
// Method contract that the analyzer cannot see
void run() {
performAction();
System.out.println("Done"); // IntelliJ flags as unreachable
}
@Contract("-> _") // Tells the analyzer: method does NOT always throw
static void performAction() { throw new AssertionError(); }解析度： 加入適當的方法契約註解（@Contract 對 IntelliJ 而言， @NotNull/@Nullable 對於 Kotlin，使用類型斷言；對於 TypeScript，使用類型斷言，以便為分析器提供所需的執行時間資訊。如果基於註解的解析不可用，請使用工具的抑制機制，並提供相應的說明。
COBOL：常假條件揭示數十年停滯不前的邏輯
在 COBOL 和傳統大型主機系統中，始終為假的條件與現代應用程式程式碼中的條件具有不同的特性，並且對於維護或現代化這些系統的團隊來說，其意義也不同。
COBOL 程式的重構方式與現代程式碼截然不同。當業務規則變更、稅法修訂、產品層級取消或監管要求更新時，常見的做法是新增邏輯而不移除舊邏輯。舊的 EVALUATE WHEN 或 IF 分支仍然保留在原始程式碼中，並且受到一個在當前資料狀態下永遠不可能為真的條件的保護。
科博爾
EVALUATE WS-PRODUCT-TYPE
WHEN 'STD'
PERFORM CALC-STANDARD-RATE
WHEN 'PRM'
PERFORM CALC-PREMIUM-RATE
WHEN 'BAS'
* BAS product type retired June 2009
* All BAS customers converted to STD
* This branch has been dead for 15+ years
PERFORM CALC-BASIC-RATE
WHEN 'LEG'
* LEG (legacy) type eliminated in 2001 system migration
* Should have been removed but was left as "just in case"
PERFORM CALC-LEGACY-RATE
WHEN OTHER
PERFORM HANDLE-UNKNOWN-TYPE
END-EVALUATE.
本次評估中的兩個枯枝， BAS 以及 LEG這些規則並非錯誤，而是歷史遺留物：它們曾在系統歷史的特定階段有效，但隨著相應產品類型的淘汰而永久失效。由於當時沒有人確定這些規則是否仍然必要，而且錯誤決策的代價似乎高於保留它們的成本，因此沒有人移除它們。
COBOL 中始終為假的條件揭示了什麼：
死枝代表不再適用的業務邏輯。 PERFORM CALC-BASIC-RATE 以及 PERFORM CALC-LEGACY-RATE 目標本身可能是整段或整段 COBOL 程式碼，每段或每段程式碼可能包含數百行，這些程式碼同樣是無效的。始終為假的條件是通往無效代碼樹的入口點，該代碼樹會沿著 PERFORM 關係傳播。
在一個 100,000 萬行的 COBOL 程式中，已棄用業務規則導致的無效分支可能佔總程式碼的 20% 到 35%。這部分程式碼屬於遷移範圍，在現代化改造專案中無需進行轉換、測試或驗證。在遷移規劃之前辨識出這些無效分支可以直接減少遷移範圍，而規劃階段的遷移範圍縮減正是始終為假條件分析最有價值的應用。
決議決策樹
Always-false condition warning received
│
▼
Is this a compile-time constant
or debug flag? (DEBUG = false, etc.)
│
Yes ───┼─── No
│ │
Intentional. ▼
Suppress or Does the condition
leave as-is. contain a logic error?
(a > 10 && a < 5, etc.)
│
Yes ───┼─── No
│ │
Fix the Has the condition
logic bug. become false due to
a past business rule
change?
│
Yes ───┼─── No
│ │
Verify, Could a runtime
then remove mechanism make
the dead it reachable?
branch. │
Yes ──── No
│
Add contract
annotation. Remove the
dead branch.壓制：何時以及如何
當該情況確實是故意為之，且工具無法獲得合約資訊以理解其原因時，抑制該情況是適當的。但抑制該情況不應作為逃避調查警告實際意義的捷徑。
Java（SonarQube）：
Java的
@SuppressWarnings("java:S2583")
if (DEBUG_MODE) { // Intentional: compile-time debug flag
dumpState();
}Java（IntelliJ）：
Java的
//noinspection ConstantConditions
if (possiblyNull != null) { // Analyzer cannot see the runtime injection
process(possiblyNull);
}Python（Pylint）：
蟒蛇
if False: # pylint: disable=W0125
# Intentional: placeholder for future implementation
passC#（SonarQube）：
尖銳的
#pragma warning disable S2589
if (IsDebugBuild) { // Compile-time constant -- intentional
LogDiagnostics();
}
#pragma warning restore S2589COBOL（SMART TS XL /自訂抑制註解）：
科博爾
*>> SUPPRESS UNREACHABLE: BAS branch retained for audit trail
WHEN 'BAS'
PERFORM CALC-BASIC-RATE
鎮壓紀律： 每一次訊息抑制都應該附帶一條說明，解釋為什麼這種抑制是故意的，而不僅僅是說明它被抑制了。一條抑制說明應該是這樣的：
// suppress unreachable比不進行任何抑制更糟糕，它隱藏了警告，卻不解釋為什麼警告是錯的。這種抑制方式顯示：// suppress: DEBUG_MODE is a compile-time constant, branch is retained for IDE visibility是可以接受的。
SMART TS XL 識別投資組合規模下的始終為假的情況
SMART TS XL“ 靜態程式碼分析 它在 COBOL、JCL、Java、Python 和環境中的所有其他語言中應用資料流和控制流程分析，以識別在投資組合規模上始終為假的條件，同時跨越數千個程序，而不是在開發人員 IDE 中一次處理一個檔案。
對於 COBOL 程式組合而言，這表示：每個程式中的每個 EVALUATE WHEN 子句和每個 IF 條件都會根據流入其中的資料的已知限制進行分析。引用產品代碼、狀態標誌或類型代碼的條件，如果其有效值集在程式的歷史記錄中發生過更改，則會被標記為潛在的死分支。輸出結果是一個死程式碼清單：包含每個程式、每個死分支以及從每個始終為假的條件可到達的死程式碼的估計行數。
遺留系統現代化分析會將這份清單轉化為範圍縮減：在任何轉換工作開始之前，所有失效分支都會從遷移規範中排除。一個看似擁有 2,000 行業務邏輯的程序，可能包含 600 行來自已停用產品類型、已刪除客戶層級和已棄用計算路徑的失效業務邏輯。遷移 1,400 行程式碼而非 2,000 行程式碼，即可將該專案的範圍縮減 30%。而失效分支是遷移範圍內風險最高的部分，因為沒有人知道它們原本的功能是什麼。
企業級搜尋功能使得對始終為假的代碼清單進行查詢成為可能：查找所有包含引用當前產品目錄中不存在的產品代碼的 EVALUATE WHEN 子句的 COBOL 程序，查找所有檢查自特定年份以來數據庫中不存在的狀態標誌值的程序，查找所有引用自編寫以來已被重新利用的數據結構字段的 IF 條件。這些查詢產生了針對性強的死程式碼清單，而人工程式碼審查需要花費數月時間才能在大規模 COBOL 程式碼庫中完成這項工作。
警告通常是正確的。
靜態分析針對始終為假的條件所發出的警告，在大多數情況下都是準確的。該條件始終為假，分支永遠不會執行，其內部的程式碼是無效的。
正確的因應措施不是壓制，而是調查。究竟是哪一種根本原因？是邏輯矛盾、業務規則的累積變更、有意為之的防禦性編程，還是運行時配置導致的工具誤報？每種情況都有正確的解決方案。其中三種會導致移除無效代碼，而另一種則會導致在給出合理理由的情況下壓制該代碼。
對於遺留的 COBOL 系統而言，大規模的「始終為假」條件分析並非主要關乎程式碼質量，而是關乎專案範圍縮減。數十年來業務規則變更累積的「死分支」意味著不應投入遷移資源。在遷移計劃最終確定之前發現這些死分支，是任何負責 COBOL 現代化專案規劃的團隊應用「始終為假」條件分析的最大價值所在。
分析器告訴你的是事實。聽它的。
