Code indentation for declaring inputs/outputs in an array

I'm writing a list of inputs and outputs for to be compared in unit tests.

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~"          ]

            ];

I've formatted it as such, so it's easy to compare and read. However, it's unconventional.

Is this a bad idea?

An argument against table-style alignment in code

Except when the editor/IDE helps maintain alignment with little work from the programmer, and all those who work with the code have that same facility, horizontal, table-like alignment in code is more trouble than it's worth, for these reasons:

-
Search/replace operations on the entire code-base (as when renaming a variable or method) will tend to leave such code in a mess that needs manual cleanup.

-
Anyone whose editor/IDE does not make horizontal alignment easy will spend a lot of time hitting space or DEL to make things line up when adding or deleting an entry.

-
When the entire table needs to be realigned (as when adding a new row that causes a column to grow), the version control system will show that the entire table changed.

For those reasons, I'm inclined to put up with a little bit of ugly:

var equals = [ //input, output
   ["name:(John Smith)", "name:(John~ Smith~)"],
   ["name:Jon~0.1", "name:Jon~0.1"],
   //...
 ];

or, as @ChrisW suggests:

var equals = [ //input, output
   [
     "name:(John Smith)",
     "name:(John~ Smith~)"
   ],
   [
     "name:Jon~0.1",
     "name:Jon~0.1"
   ],
   //...
 ];

But maybe data doesn't want to be in the code

Sometimes data wants its own home, a place where "rows and columns" are more natural than in code. Perhaps that's a table in the database. In your case, where the table is input to a test, a .csv file might be good. A non-technical user could then view and edit the data with a spreadsheet program.

StackExchange Code Review Q#39845, answer score: 28