Revo的正則表達式是正確的做法(就像正則表達式一樣!)。
但有時您只需要快速操作一個您可以控制的文件。我發現,在使用正則表達式時,定義「足夠好」通常很重要。
因此,假定縮進是正確的,可能是「足夠好」。在這種情況下,你可以檢測FN的開始,接着看,直到你用相同的縮進找到下一個右花:
( # Capture \1.
^([\t ])+ # Match and capture leading whitespace to \2.
(?:\w+\s*)? # Privacy specifier, if any.
\w+\s*\( # Name and opening round brace: is a function.
.*? # Need Dot-matches-newline, to match fn body.
\n\2} # Curly brace is as indented as start of fn.
) # End capture of \1.
應該是你自己寫乾淨的代碼工作,代碼,您可以通過首先是自動格式化程序等。
將與K & R,Hortmann和Allman indent styles一起使用。
將失敗單線和內聯功能,以及像GNU,Whitesmiths,Pico,Ratliff和Pico這樣的縮進樣式 - Rico的答案完全沒有問題。
對於使用泛型的lambda函數,嵌套函數和函數也失敗了,但即使Revo's也無法識別這些,並且它們並不常見。
而我們的正則表達式都不會捕獲函數前面的註釋,這是相當有罪的。
不是很簡單。你有平衡的文本是範圍分隔符,可以隱藏在引號和註釋中。那麼,你至少需要考慮3件事情,並寫出一個非常龐大而複雜的正則表達式。我會收取錢來做這個。當然,該功能本身可以隱藏在評論或引用中。 – sln
爲什麼?我的意思是說像這樣說會變得很複雜。但是什麼是垃圾?並且有多少匹配的字符串示例('在所有目錄中都有?)如果匹配少於20,則手動更快。 –
這只是爲了替換文件中的函數,而不必手動執行,原因。 –