「易於維護的主要特點是局部性：局部性是指原始碼的特性，讓程式設計師只需查看原始碼的一小部分即可理解該原始碼。」– Richard Gabriel
行為局部性 (Locality of Behaviour) 的原則是
程式碼單元的行為，應該盡可能只透過查看該程式碼單元就能清楚了解
LoB 原則是 Richard Gabriel 引言中陳述的簡單規範。 在盡可能的情況下，並在與其他考量因素平衡的情況下，開發人員應努力使程式碼元素的行為在檢查時顯而易見。
考量一下在 HTML 中實現 AJAX 請求的兩種不同方式，第一種使用 htmx
<button hx-get="/clicked">Click Me</button>
第二種使用 jQuery
$("#d1").on("click", function(){
$.ajax({
/* AJAX options... */
});
});
<button id="d1">Click Me</button>
在前者的例子中，button 元素的行為在檢查時顯而易見，符合 LoB 原則。
在後者的例子中，button 元素的行為分散在多個檔案中。 如果沒有對整個程式碼庫有完整的了解，很難確切知道按鈕的功能。 這種「遠距離的詭異作用」是維護問題的根源，並阻礙開發人員理解程式碼庫。
htmx 的範例展示了良好的行為局部性，而 jQuery 的範例則具有較差的行為局部性。
對於行為局部性一個常見的反對意見是，它將實作細節內嵌在程式碼單元中，使程式碼單元變得較不抽象且更脆弱。 然而，重要的是要區分內嵌行為的實作與內嵌行為的調用（或宣告）。
以大多數程式語言中的函式為例：函式的宣告與其在調用位置的使用之間存在區別。 一個好的函式會抽象化其實作細節，但也會以顯而易見的方式調用，而不會產生任何遠距離的詭異作用。
在其他條件不變的情況下，增加元素行為的顯著性是一件好事，但終端開發人員，尤其是框架開發人員，應盡可能使 LoB 既容易又在概念上清晰。
LoB 經常會與其他軟體開發原則產生衝突。 其中兩個重要的原則是
軟體開發人員通常會努力避免程式碼或資料中的冗餘。 這就是所謂的「保持 DRY」，即不要重複自己。 像其他軟體設計原則一樣，這本身是一件好事。 例如，htmx 允許您在 DOM 中的父元素上放置許多屬性，並避免在子元素上重複這些屬性。 這是違反 LoB 的，而有利於 DRY，開發人員需要謹慎地做出此類權衡。
請注意，行為離其影響的程式碼單元越遠，對 LoB 的違反就越嚴重。 如果它在程式碼單元的幾行之內，則不如它在一頁之外嚴重，而後者又不如它在一個完全獨立的檔案中嚴重。
沒有硬性規定，而是軟體開發人員必須做出主觀的權衡。
關注點分離是一種將電腦程式分成不同部分的設計原則，以便每個部分處理單獨的關注點。 這方面的一個典型例子是拆分 HTML、CSS 和 Javascript。 同樣，就其本身而言，並且在孤立的情況下，這可能確實是一件好事。 內嵌樣式 最近變得更加普遍，但在此方面仍然有強而有力的理由支持 SoC。
請注意，SoC 與 LoB 衝突。 通過調整 CSS 檔案，元素的視覺外觀以及某種程度的行為可能會發生巨大變化，而這種巨大變化來自哪裡並不清楚。 工具可以在某種程度上提供幫助，但仍然存在「遠距離的詭異作用」。
再次強調，這不是要全盤否定 SoC，只是要說明在考慮如何組織程式碼時必須做出主觀的權衡。 近期內嵌樣式變得更加普遍的事實表明，SoC 在開發人員之間的支持度正在下降。
LoB 是一個主觀的軟體設計原則，可以幫助使程式碼庫更加人性化且更易於維護。 它必須與其他設計原則進行權衡，並且必須根據編寫程式碼單元的系統限制進行考慮，但是，在可行的範圍內，堅持此原則將提高軟體的可維護性、品質和永續性。