|
1。地球人都知道 C# 中 字符串常量可以以 @ 開頭聲名，這樣的優(yōu)點是轉(zhuǎn)義序列“不”被處理，按“原樣”輸出，即我們不需要對轉(zhuǎn)義字符加上 \ （反斜扛），就可以輕松coding。如，  string filePath = @"c:\Docs\Source\a.txt" // rather than "c:\\Docs\\Source\\a.txt"2。如要在一個用 @ 引起來的字符串中包括一個雙引號，就需要使用兩對雙引號了。 @"""Ahoy!"" cried the captain." // 輸出為： "Ahoy!" cried the captain.有點像SQL中的單引號常量處理方式： DECLARE @msg varchar(100)SET @msg = ‘‘Ahoy!‘‘ cried the captain.‘ -- 輸出為： ‘Ahoy!‘ cried the captain.3。@ 會識別換行符 其實這個特性，我不知道怎么描述，只是偶然發(fā)現(xiàn)的，先看下面的代碼吧： string script = @" <script type=""type/javascript""> function doSomething() { } </script>";安逸吧，在cs文件中寫js，結(jié)構(gòu)就很清晰了，正常情況我們是這樣coding的： string script2 = "<script type=\"type/javascript\">function doSomething(){}</script>";// orstring script3 = "<script type=\"type/javascript\">" + "function doSomething(){ " + "}</script>";通常我們會選擇后者，因為js代碼一般比較長，或者方法體很大，或者需要連接其他變量，這樣結(jié)構(gòu)比較清晰。 注意：如果“拼接”的次數(shù)很多，應(yīng)該考慮使用StringBuilder了，有助于提高性能。 還有一種場景，也很常見，在程序中拼接 SQL 語句，如 private const string SQL_INS_USER = @" INSERT INTO t_User([UserName], [Password], Email) VALUES(@UserName, @Password, @Email)";哈哈，這樣就像寫存儲過程一般，保持相當高的代碼清晰度。 然而，我們需要關(guān)注一個問題：字符串長度 看下面的測試代碼： private const string SQL_INS_USER1 = @" INSERT INTO t_User([UserName], [Password], Email) VALUES(@UserName, @Password, @Email)"; private const string SQL_INS_USER2 = @"INSERT INTO t_User([UserName], [Password], Email) VALUES(@UserName, @Password, @Email)"; private const string SQL_INS_USER3 = @"INSERT INTO t_User([UserName], [Password], Email) VALUES(@UserName, @Password, @Email)"; static void Main(string[] args) { Console.WriteLine(SQL_INS_USER1.Length); // 126 Console.WriteLine(SQL_INS_USER2.Length); // 112 Console.WriteLine(SQL_INS_USER3.Length); // 86 }可以看到三個字符串長度分別相差了，14=126-112和26=112-86，注意觀察了，在代碼編輯器中，SQL_INS_USER1 中第一個換行符號之后，我縮進13個空格（INSERT之前），而 SQL_INS_USER2 中第一個換行符號之后，我縮進25個空格（VALUES之前）， 那么，加上一個換行符，剛剛好 14和26 My GOD！ 如此編寫代碼，雖然提高了代碼的清晰度和簡便性，卻無行中帶來了另一個問題：字符長度！ 很多場景下我們希望字符串越短越好，如，通過ADO.NET 發(fā)送 SQL 語句給數(shù)據(jù)庫執(zhí)行。 所以還是慎用之！ |
|
|
