1。地球人都知道C#中字符串常量可以以@开头声名,这样的优点是转义序列“不”被处理,按“原样”输出,即我们不需要对转义字符加上\(反斜扛),就可以轻松coding。如
这时候你不能使用\来转义爽引号了,因为在这里\的转义用途已经被@“屏蔽”掉了。如
有点像SQL中的单引号常量处理方式:
3。@会识别换行符
其实这个特性,我不知道怎么描述,只是偶然发现的,先看下面的代码吧:
安逸吧,在cs文件中写js,结构就很清晰了,正常情况我们是这样coding的:
通常我们会选择后者,因为js代码一般比较长,或者方法体很大,或者需要连接其他变量,这样结构比较清晰。
注意:如果“拼接”的次数很多,应该考虑使用StringBuilder了,有助于提高性能。
还有一种场景,也很常见,在程序中拼接SQL语句,如
哈哈,这样就像写存储过程一般,保持相当高的代码清晰度
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.
SET @msg = ''Ahoy!'' cried the captain.' -- 输出为: 'Ahoy!' cried the captain.
3。@会识别换行符
其实这个特性,我不知道怎么描述,只是偶然发现的,先看下面的代码吧:
string script = @"
<script type=""type/javascript"">
function doSomething()
{
}
</script>";
<script type=""type/javascript"">
function doSomething()
{
}
</script>";
安逸吧,在cs文件中写js,结构就很清晰了,正常情况我们是这样coding的:
string script2 =
"<script type=\"type/javascript\">function doSomething(){}</script>";
// or
string script3 =
"<script type=\"type/javascript\">" +
"function doSomething(){ " +
"}</script>";
"<script type=\"type/javascript\">function doSomething(){}</script>";
// or
string script3 =
"<script type=\"type/javascript\">" +
"function doSomething(){ " +
"}</script>";
通常我们会选择后者,因为js代码一般比较长,或者方法体很大,或者需要连接其他变量,这样结构比较清晰。
注意:如果“拼接”的次数很多,应该考虑使用StringBuilder了,有助于提高性能。
还有一种场景,也很常见,在程序中拼接SQL语句,如
privateconststring SQL_INS_USER = @"
INSERT INTO t_User([UserName], [Password], Email)
VALUES(@UserName, @Password, @Email)";
INSERT INTO t_User([UserName], [Password], Email)
VALUES(@UserName, @Password, @Email)";
哈哈,这样就像写存储过程一般,保持相当高的代码清晰度
然而,我们需要关注一个问题:字符串长度
看下面的测试代码:
看下面的测试代码:
privateconststring SQL_INS_USER1 = @"
INSERT INTO t_User([UserName], [Password], Email)
VALUES(@UserName, @Password, @Email)";
privateconststring SQL_INS_USER2 = @"INSERT INTO t_User([UserName], [Password], Email)
VALUES(@UserName, @Password, @Email)";
privateconststring SQL_INS_USER3 = @"INSERT INTO t_User([UserName], [Password], Email) VALUES(@UserName, @Password, @Email)";
staticvoid Main(string[] args)
{
Console.WriteLine(SQL_INS_USER1.Length); // 126
Console.WriteLine(SQL_INS_USER2.Length); // 112
Console.WriteLine(SQL_INS_USER3.Length); // 86
}
INSERT INTO t_User([UserName], [Password], Email)
VALUES(@UserName, @Password, @Email)";
privateconststring SQL_INS_USER2 = @"INSERT INTO t_User([UserName], [Password], Email)
VALUES(@UserName, @Password, @Email)";
privateconststring SQL_INS_USER3 = @"INSERT INTO t_User([UserName], [Password], Email) VALUES(@UserName, @Password, @Email)";
staticvoid 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
MyGOD!
如此编写代码,虽然提高了代码的清晰度和简便性,却无行中带来了另一个问题:字符长度!
很多场景下我们希望字符串越短越好,如,通过ADO.NET发送SQL语句给数据库执行。
所以还是慎用之!
SQL_INS_USER2中第一个换行符号之后,我缩进25个空格(VALUES之前),
那么,加上一个换行符,刚刚好14和26
MyGOD!
如此编写代码,虽然提高了代码的清晰度和简便性,却无行中带来了另一个问题:字符长度!
很多场景下我们希望字符串越短越好,如,通过ADO.NET发送SQL语句给数据库执行。
所以还是慎用之!