>您剛剛進入了一個現有項目以替換離職的開發人員。或者，也許您剛剛從幾年前開放了您的舊項目。查看代碼時，您會面臨恐懼和恐懼。您只能做一件事：清理這個混亂！這聽起來對您熟悉嗎？當然，我們都在某個時候或另一個時刻遇到了這一點。
>您知道清理CSS代碼庫將是一項巨大的任務。有很多事情要做，但是時間卻很少 - 尤其是當客戶/老闆/同事倡導好善良的“不要修復沒有破壞的東西”的格言時。您真的不知道從哪裡開始！
>>好吧，您很幸運，因為我已經完成了CSS清理工作的份額，我在這裡給您一些提示以開始。這全都是要抓住低懸掛的水果。
SASS具有一個基於紅寶石的linter，稱為scss-lint。您可以自己配置它，或從Sass-Guidelines中獲取推薦的配置文件，以立即開始。還有一個node.js版本稱為sass-lint，儘管它們不是100％可互用的，因此您的里程可能會有所不同。
>>嘗試在您的SASS文件夾上運行SCSS-lint以檢查錯誤。很可能會被錯誤牆淹沒。通常，這是您要放棄的時間。但是忍受我！在這一點上，您可以嘗試使您不在乎的規則（例如顏色格式）使您的絨布文件變得不太嚴格，也可以將其前面處理並從中地獄來解決野獸！
是時候修復需要修復的內容了。有兩種方法。第一個是一個一個一個一個，一個一個似乎是錯誤和/或奇怪的內容，例如命名差異不好的慣例，過於深度的nest-nest選擇器，格式較差的代碼等。第二個（和我最喜歡的）是啟動進行一些搜索和替換。我不認識你，但我喜歡正則表達式，所以當我必須這樣做時，總是很有趣。
> 例如，假設您要在所有浮點數的前面（即0到1之間的數字值）（即SCSS-LINT的LeadingZero規則）中添加缺失的前導零。您可以搜索s。 （d）（所有數字之後的所有數字和一個點），然後用0。 $ 1（空間，零，點和找到的數字）。或者，如果您想尊重SCSS-lint的BorderZero規則，則可以替換邊框：無邊框：IDE中的0。簡單如派！>我最近在Github上啟動了SCSS-LINT-REGEX存儲庫，以在一個地方收集這些正則表達式。如果您正在努力覆蓋大型項目，請務必看看。還要通過搜索和更換，因為它有時會產生意外的副作用。每次替換後，請確保執行git差異以檢查已更新的內容，以確保您不引入錯誤。
>
>完成橫向編輯後，您將不會逃脫手動文件爬行以清潔需要清潔的所有內容（凹痕不良，缺失或額外的空線，缺失空間等）。這需要大量時間，但是對於下一步會有很大幫助，因此從此開始很重要。>
修改結構>只要您對它感到滿意並堅持下去，您選擇哪種方法並不重要。可能是SMACS，可能是7-1，它可以ITCSS - 選擇您的選擇！然後嘗試重組事物，使代碼符合所選方法。我主要使用SASS指南中引入的7-1模式，因此，如果您決定這樣做，我會為您提供一些提示。
>>從>供應商開始，因為它是沒有問題的文件夾。將任何未包裝的第三方庫移動到那裡（即，任何未通過NPM或Bundler視為常規依賴性的庫）。 > 然後，轉到
摘要文件夾。確保項目定義的所有變量，混合素，功能和占位符。只要您最終在代碼庫的所有文件中都沒有變量和混音，就可以隨時按照您想要的方式組織它。當時我還傾向於尋找不必要的變量（和混合物）。確實，我經常發現無數使用一次或兩次使用的變量（換句話說，不值得）。 > 完成後，就是您的電話。您可以嘗試確保
> base文件夾中的所有內容實際上都是基本的東西，而不是相關的組件，或者您可以查看佈局文件夾，以檢查是否所有有關總體佈局居住在那裡，並正確記錄了。 > 最後，您將不得不解決>組件
，這可能是一項巨大的任務。我在這裡的建議是嘗試使組件盡可能小且可重複使用。只要您使它們使它們上下文不可知，並且易於閱讀，理解和更新。 例如，擁有如此小的組件是一件不好的事情：> 思考模塊化。小的。簡單的。獨立。
刪除多餘的
<span><span>.quote</span> {
</span> <span>padding: 10px;
</span><span>}
</span>
<span><span>.quote__attribution</span> {
</span> <span>font-size: 80%;
</span><span>}
</span>
<span><span>.quote > :first-child</span> {
</span> <span>margin-top: 0;
</span><span>}
</span>
<span><span>.quote > :last-child</span> {
</span> <span>margin-bottom: 0;
</span><span>}</span>已經超過3年了，但是尼古拉斯·加拉格爾（Nicolas Gallagher）的推文仍然是我最喜歡的有關CSS的報價：
寫作css時，我想在進行CSS工作之前想做的事情正在打開開發人員工具，並切換我寫的每份CSS聲明，以查看它們是否都有影響。如果他們不這樣做，我問自己為什麼他們首先在那裡。如果事實證明它們是不必要的，我將其刪除。通過做一些簡單的事情，我確保只有有用的無用的無垃圾代碼才能將其推向存儲庫。
>清理 css代碼庫沒有什麼不同。找到您想清理的組件，打開DevTools，然後嘗試查找無用的聲明。有時，為了刪除某些CS，我們需要移動樹上的一些樣式，以使級聯受益。考慮以下示例減少到最低限度：
<span><span>.quote</span> {
</span> <span>padding: 10px;
</span><span>}
</span>
<span><span>.quote__attribution</span> {
</span> <span>font-size: 80%;
</span><span>}
</span>
<span><span>.quote > :first-child</span> {
</span> <span>margin-top: 0;
</span><span>}
</span>
<span><span>.quote > :last-child</span> {
</span> <span>margin-bottom: 0;
</span><span>}</span>>一種優化的干淨方法是將顏色移動：紅色聲明向父母移動，讓級聯的其餘部分。當然，現實生活中的例子通常更為複雜，但這表明我們有時會忘記在 *c *ss。 中利用> c
不良的方法：>
<span><span>.parent</span> {
</span> <span>/* ...stuff here... */
</span><span>}
</span>
<span><span>.child-A</span> {
</span> <span>color: red;
</span><span>}
</span>
<span><span>.child-B</span> {
</span> <span>color: red;
</span><span>}</span>>
> CSS具有一種內置的處理方式，並具有繼承的值。那樣簡單。因此，鏈接將始終繼承其父母的顏色。這也可能正在繼承其祖先的顏色，依此類推。
<span>a {
</span> <span>color: black; /* Nope */
</span><span>}</span>按照相同的行，將財產重新定位到其默認值時，對硬碼所述值是一個糟糕的想法。對於這種情況，CSS具有最初的魔術價值。雖然通常不會有所作為，但在某些情況下確實很重要，例如基於方向的屬性，例如文本對準。重置文本單位時，剩餘的設置可能會損壞RTL語言；最初是要走的路（甚至更好，開始，但是此值在IE9中沒有支持）。
>最後但並非最不重要的一點是，CSS開發人員的數量不知道CurrentColor太高了。如果您不知道，不要感到難過，但是請問自己：當不指定邊框顏色時，它如何自動匹配元素的顏色？好吧，這是因為邊界色的默認值是CurrentColor（檢查規格）。一個顯而易見的名字，你會承認。>
>我的意思是，如果您希望與元素字體共享顏色，請使用CurrentColor而不是硬編碼值或SASS變量。
<span><span>.quote</span> {
</span> <span>padding: 10px;
</span><span>}
</span>
<span><span>.quote__attribution</span> {
</span> <span>font-size: 80%;
</span><span>}
</span>
<span><span>.quote > :first-child</span> {
</span> <span>margin-top: 0;
</span><span>}
</span>
<span><span>.quote > :last-child</span> {
</span> <span>margin-bottom: 0;
</span><span>}</span>讓您的git好
。您可能會更新數十個文件。您也很可能會沿途破壞事情。老實說，我們都會犯錯誤，在處理如此巨大的變化時，如果您成功地清理所有東西而沒有小小的失誤，那將是非常令人印象深刻的。 > 因此，我強烈建議您對自己的版本控制變得非常刻板（我認為可以在此處假設GIT公平）。這意味著要做一件事，而只有一件事才能回到包含一個錯誤的步驟，而不會像地獄一樣掙扎著衝突。
>
我知道很多人的git是艱難而晦澀的，並且挖掘如何使其變得簡單的方式超出了本文的範圍。不過，您必須相信我：如果您不想生氣，請使您的GIT歷史成為一首詩。
>將其包裹起來
>
>從覆蓋您的代碼開始，使其變得漂亮。首先，以使您的生活以後更輕鬆。這也是獲得有價值的代碼庫狀態而不會冒險的好方法（修復語法污垢不太可能造成任何麻煩）。接下來，請確保您的項目包含結構方法。只要做得好，哪一個都沒關係。如果您的項目並沒有真正精心策劃為組件，那麼這將是一個開始這一道路的好機會。找到可重複使用的界面塊，並將其樣式提取到自己的部分中。可以隨意記錄一下它們，這樣就變得更容易了，並且您會感覺到進步。
>一旦您清理了項目並將所有內容都放在正確的位置，就該改善CSS本身了。檢查是否可以先刪除內容；我們經常編寫太多的代碼。然後嘗試優化代碼，以使其重複性降低。當心不要過度工程！您應該消除複雜性，而不是添加。還可以隨意評論您所做的所有事情，這可能乍一看似乎並不明顯。
最後但並非最不重要的一點是，不要忘了慶祝完成。祝你好運！
經常詢問的問題（FAQ）有關清理CSS代碼庫
清理CSS代碼庫的重要性是什麼？ >清理CSS代碼庫至關重要。首先，它提高了代碼的可讀性，使其他開發人員更容易理解和工作。其次，隨著不必要或冗餘代碼的刪除，它可以提高網站或應用程序的性能。這可以導致更快的負載時間和更好的用戶體驗。最後，乾淨的代碼庫更易於維護和調試，從長遠來看節省了時間和資源。 如何識別冗餘或不必要的CSS代碼？>幫助確定未使用或冗餘的CSS代碼。其中包括瀏覽器開發人員工具，CSS覆蓋工具和各種在線服務。此外，手動代碼審查也可能是有益的，特別是對於確定代碼中的冗餘或不一致。 CSS代碼庫包括刪除未使用或冗餘代碼，以邏輯和一致的方式組織代碼，使用註釋來解釋代碼的複雜部分，並粘附達成一致的命名慣例。此外，使用CSS預處理器可以幫助管理和維護大型代碼庫。
>> CSS預處理器在清理CSS代碼庫中的作用是什麼？清理CSS代碼庫。它允許使用變量，嵌套，混合物和其他可以使代碼更可讀和可維護的功能。此外，它可以幫助自動化諸如縮小和自動固定之類的任務，從而進一步提高代碼庫的清潔度和效率。
>清理CSS代碼庫可以通過減少瀏覽器下載和解析的代碼數量來改善網站性能。這可能會導致加載時間更快，並獲得更順暢的用戶體驗。此外，刪除不必要的或冗餘的代碼可以減少可能影響性能的衝突或錯誤的可能性。
>>
>我可以使用哪些工具來自動清理CSS代碼庫的過程？ 🎜>有幾種可以自動化清理CSS代碼庫的工具。這些包括CSS預處理器，襯里和微型儀。此外，還有一些在線服務可以分析您的代碼庫並確定改進的區域。 >我應該多久清理一次CSS Codebase？>
> > CSS Codebase清理的頻率取決於幾個因素，包括代碼庫的大小，從事其工作的開發人員數量以及項目的複雜性。但是，作為一般規則，定期的代碼審查和清理應成為開發過程的一部分，以確保代碼庫保持清潔和可維護。>
>清理CSS代碼庫有哪些挑戰？ >清理CSS代碼庫可能是一項複雜的任務，尤其是對於大型舊代碼庫。挑戰可能包括識別未使用或冗餘代碼，保持與較舊瀏覽器的兼容性，並確保更改不會破壞現有功能。此外，這可能是耗時的，尤其是沒有使用工具來自動化過程的情況。以上是清理CSS代碼庫的詳細內容。更多資訊請關注PHP中文網其他相關文章！
