var equals = [
//input //output
["name:(John Smith)", "name:(John~ Smith~)" ],
["name:Jon~0.1", "name:Jon~0.1" ],
["Jon", "Jon~" ],
["Jon Smith~0.1", "Jon~ Smith~0.1" ],
["Jon AND Bob", "Jon~ AND Bob~" ],
["Jon AND Bob~0.1", "Jon~ AND Bob~0.1" ],
["Steve^9 Jon", ] "Steve^9 Jon~" ]
];
我已经对它进行了格式化，因此比较和阅读都很容易。但是，这是非常规的。
这是个坏主意吗？
#1 楼
反对代码中的表格样式对齐的论点除非编辑器/ IDE不需要程序员的辛苦工作就能保持对齐，并且所有使用该代码的人都具有相同的功能，即水平，表格，由于以下原因，例如代码中的对齐比它值得的麻烦更多：
在整个代码库上的搜索/替换操作（如重命名变量或方法时）将趋于消失这样的代码很混乱，需要手动清理。
编辑器/ IDE不能使水平对齐变得容易的任何人，在添加或删除条目时，都将花费大量时间来敲打空格或DEL以使内容对齐。
当需要重新调整整个表时（如添加导致列增长的新行时），版本控制系统将显示整个表已更改。
由于这些原因，我m倾向于忍受一点丑陋：
var equals = [ //input, output
["name:(John Smith)", "name:(John~ Smith~)"],
["name:Jon~0.1", "name:Jon~0.1"],
//...
];
，或者如@ChrisW所建议的那样：
var equals = [ //input, output
[
"name:(John Smith)",
"name:(John~ Smith~)"
],
[
"name:Jon~0.1",
"name:Jon~0.1"
],
//...
];
Bu也许数据不想放在代码中
有时数据想要自己的家，在这里，“行和列”比代码中的更为自然。也许那是数据库中的一个表。在您的情况下，将表输入到测试中，.csv文件可能不错。然后，非技术用户可以使用电子表格程序查看和编辑数据。
评论
\ $ \ begingroup \ $
还有第二种选择是否也可以接受，即将每个输出字符串在其输入字符串下方左对齐？ IMO可能使在视觉上将每个输出与其输入进行比较变得容易。
\ $ \ endgroup \ $
– ChristW
2014年1月22日23:02
\ $ \ begingroup \ $
例如，[[Jon]换行符“ Jon〜”]使得，位于[？
\ $ \ endgroup \ $
– ChristW
2014年1月22日23:04
\ $ \ begingroup \ $
我不同意这个答案。通常，读取代码的频率高于编写代码的频率，因此付出额外的努力是值得的。表格数据应在代码中具有表格布局。良好的格式可以更容易发现错误。
\ $ \ endgroup \ $
–阿蒙
2014年1月22日23:06
\ $ \ begingroup \ $
+1看起来不错（比我的建议要好）。您还可以通过在每个输出之后（与之相同的行上）使用[]来节省垂直空间。
\ $ \ endgroup \ $
– ChristW
2014年1月22日23:44
\ $ \ begingroup \ $
好的答案，谢谢韦恩。这是关于同一个主题的程序员SE问题，我提到将其放入CSV。有比一系列“ AssertEquals”更好的编写单元测试的方法吗？
\ $ \ endgroup \ $
– dwjohnston
2014年1月23日在21:33
#2 楼
从DRY角度来看，您的代码应可用于生成文档，例如“此例行程序支持哪些用例”或“ y和z之间的映射值是什么？”，这始终是一个棘手的问题。'。
所以我肯定会对齐我的表，但是我也倾向于对齐逗号，并且我倾向于将2个空格对齐，而不是一直到var的右边。
换句话说，是这样的：
var equals =
[
//input //output
["name:(John Smith)", "name:(John~ Smith~)"],
["name:Jon~0.1" , "name:Jon~0.1" ],
["Jon" , "Jon~" ],
["Jon Smith~0.1" , "Jon~ Smith~0.1" ],
["Jon AND Bob" , "Jon~ AND Bob~" ],
["Jon AND Bob~0.1" , "Jon~ AND Bob~0.1" ],
["Steve^9 Jon" , "Steve^9 Jon~" ]
];
评论
\ $ \ begingroup \ $
您能说这比其他答案有什么好处吗？
\ $ \ endgroup \ $
– ChristW
2014年1月23日下午0:42
\ $ \ begingroup \ $
@ChrisW Aesthetics（这是主观的，并且取决于个人喜好）。我也喜欢这个版本，尽管我倾向于不对齐逗号，因为逗号前的空格对我来说像是不适当的标点符号，并像不对齐的表格一样在我的头上造成了恼人的压力点。不烦我是我的代码需要具备的重要优势。 :-)不过，我倾向于在非常小的团队中工作。 （客观缺点在另一个答案中有很好的表述。）
\ $ \ endgroup \ $
–安德烈·塔兰佐夫（Andrey Tarantsov）
2014年1月23日在3:03
\ $ \ begingroup \ $
@ChrisW根据我的回答，文档，尤其是我提供给非技术人员的文档，他们理解这种格式，而其他答案对于非技术人员来说是难以理解的。
\ $ \ endgroup \ $
– konijn
2014年1月23日在3:04
\ $ \ begingroup \ $
我一般不对齐逗号，因为我不喜欢它的外观。但是，这样做的好处是，它使使用块选择将声明的任何列复制到例如默认赋值或验证代码段变得更加容易。
\ $ \ endgroup \ $
–博伊西
2014年1月23日，7:55
\ $ \ begingroup \ $
@konijn-是否向非技术人员提供代码作为文档？
\ $ \ endgroup \ $
–韦恩·康拉德
2014年1月23日下午13:38
#3 楼
从纯代码审查的角度来看，不是解决直接的问题“我应该以表格方式格式化单元测试数据”，而是这是首先写入此数据的最佳方法吗？如果您考虑编写单元测试，那么这样做是否更具可读性/可维护性？
var equals =
[
//input //output
["name:(John Smith)", "name:(John~ Smith~)"],
["name:Jon~0.1" , "name:Jon~0.1" ],
["Jon" , "Jon~" ],
["Jon Smith~0.1" , "Jon~ Smith~0.1" ],
["Jon AND Bob" , "Jon~ AND Bob~" ],
["Jon AND Bob~0.1" , "Jon~ AND Bob~0.1" ],
["Steve^9 Jon" , "Steve^9 Jon~" ]
];
foreach(var item in equals){
Assert.Equal(Sut.Process(item.Key), item.Value)
}
或者也许您应该简单地写出断言/测试：
Assert.Equal(Sut.Process("name:(John Smith)"), "name:(John~ Smith~)")
Assert.Equal(Sut.Process("name:Jon~0.1"), "name:Jon~0.1")
etc
如果您认为应该使用列表，请使用结构化类型而不是数组，尽管它的类型更多，但更易于阅读：
var params =
[{
Input: "name:(John Smith)",
Output: "name:(John~ Smith~)"
},{
Input: "name:Jon~0.1",
Output: "name:Jon~0.1"
}]
for(var expect in params){
Assert.Equal(Sut.Process(expect.Input), expect.Output)
}
以这种方式格式化数据没有好处，除非您使用的是为您管理数据的编辑器。可读性没有得到很大提高（考虑到我的屏幕分辨率是否低于您，甚至可能看不到它），维护这种格式的工作远远超过了这样做的好处。同意，测试应尽可能地易读，这就是为什么数组可能不是首先写入此数据的最佳选择的原因。
评论
我想一个可能的问题是，它可能会溢出到不同的编辑器/屏幕尺寸上，并且看起来很糟糕。