StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I think your "table-based" example <em>is</em> far easier to read, on its own. The problem is that we've got 50 years of text-based tools for dealing with source code as <em>lines</em> of text. The two most obvious problems that you'll run into with this are:</p> <ol> <li><p>All my favorite text-handling tools, like <code>diff</code> and <code>grep</code>, work on lines. The more you put on one line, the less value my tools have. For example, if I want to grep for something in the if's condition, I have to filter false positives from the ifTrue clause.</p> <p>(If you're writing in a language with more regular syntax in an extensible editor, like Lisp inside Emacs, this isn't as much of a problem, since it's trivial to traverse the actual structures. But C# has very complex syntax, and I don't know of an easy way to traverse my C# code with 1 or 2 lines of code, so text tools still reign here.)</p></li> <li><p>Your longest line is about 95 characters -- and that's with <code>..</code> in place of actual args, so it'd be even longer. Really long lines can be a pain to work with. Lines of varying width (since most of my lines won't be that long) mean wasted screen space, since my windows are all rectangular. Or I have to keep resizing windows when I scroll. Any way I look at it, editors and tools are great at handling files with many lines, but pretty lousy at handling lines of wide and varying lengths.</p></li> </ol> <p>I'd like writing this code. I'd love reading this code. I would really hate having to do a 3-way merge on this code. :-)</p> <p>In contrast, I'm going to go out on a limb and say I think most of the other answers here so far are bunk:</p> <ul> <li>various things about char <code>0x09</code>: well, use spaces and not tabs, then; that's just common sense these days</li> <li>monospaced fonts: all <em>kinds</em> of code standards I've seen fall over if you use a variable-width font, not just this</li> <li>"it's the convention": OK, but that doesn't say why it's the convention, or why this case shouldn't be an exception to the convention (because every set of code conventions I've ever seen allow exceptions)</li> <li>StyleCop says it's bad: are you working for your tools, or are they working for you? see also: "it's the convention"</li> <li>it's hard to maintain: not in my editor, and if it's hard in your editor, you need to learn how to use it, or get a better one</li> <li>some people won't have your editor: do all your coding standards depend on it being easy to write with an arbitrarily wimpy editor? If we hire somebody who insists on using Notepad, that's <em>their</em> problem, and we're not going to change our source code for them. See also: "it's hard to maintain"</li> <li>it's inconsistent: sure, but (since I'm not a robot) that doesn't necessarily make something harder to read; every comic strip in my newspaper is formatted differently (in some cases <em>really</em> differently!), yet I don't find any of them at all difficult to read</li> </ul> <p>(Flame away!)</p> <p>In the end, I think both of these styles are kind of lousy for this kind of code, for different reasons. If you need a table of stuff, then use <code>switch</code>, or an <code>IDictionary<ResultType,Action></code>, or a list-of-lists or -tuples (if order matters), or offload the rules into a config file, or something. You're right to think that a table should look like a table. The only thing you're missing is that we've got constructs to make things look like tables that would work just fine here, and <code>if</code> isn't one of them. :-)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload