On Thu, May 17, 2012 at 4:50 PM, Maciej Stachowiak <[email protected]> wrote: > > On May 17, 2012, at 4:40 PM, Dirk Pranke <[email protected]> wrote: > >> On Thu, May 17, 2012 at 4:16 PM, Maciej Stachowiak <[email protected]> wrote: >>> >>> Let's take an example. "TEXT" next to a test name apparently means that the >>> text fails. There is no way in the world I would guess that just from >>> reading an expectations file. This is only conceivably understandable to >>> someone who is an expert on the format. If someone used TEXT in code to >>> mean "fail", I would r- their patch for failure to use meaningful >>> identifiers. >>> >> >> I hardly think you have to be an expert on the format. I think you >> probably need it explained to you once, or you could just read >> http://trac.webkit.org/wiki/TestExpectations (which is linked to from >> (I think) all of the expectations files). > > If someone gave that kind of explanation for a variable in a patch to C++ > code, I would still r- their patch. The token's meaning should be apparent > without having to read out-of-line docs first. >
Fair enough. I am not attempting to suggest that these are the best possible names. I'm just objecting to the claim that you need to be an expert to understand them. >> At the risk of overly repeating myself, I am not wedded to any one >> format here, but I'm also not inclined to change things just because a >> couple of people have vocally objected. If there was a clear consensus >> that any change was preferred, that's fine by me. > > I feel like the people objecting to change, you included, are objecting > because mostly because they are already familiar and comfortable with the > current format. And not because it is genuinely better than another format > that people might be similarly experienced with in the future. It is totally > possible to be both newbie-friendly and experienced-friendly if you do not > limit "experienced" to only the people who already have experience today. I probably polarized things by saying that your input was less valuable than those of people who were long-time users. I did not mean to offend, and I'm sorry. I certainly didn't mean to imply that I was not listening or not open to feedback from anyone, and I hope I've made that clear. That does not mean I will agree to any proposal without argument, obviously. As Ojan keeps pointing out, pretty much everyone in the "objecting to change" camp has in fact indicated several things they'd be happy to change, and in fact we've all mostly agreed on them. In addition, I believe the people who have indicated that they like the existing format have given reasons for WHY -- :) -- they like it: the format allows them to quickly and easily chunk the line, and it separates the platform configuration and other modifiers from the expected outcomes, so that it's easier to see each group. The "put all the keywords together" idea does not have these properties, and that's why we don't like it. Other proposals, like your use of column formatting, and rniwa's use of brackets, are improvements. Your column formatting proposal did have some obvious drawbacks, but I haven't actually seen anyone object too much to rniwa's latest proposal. I personally don't care for the mixed-case names (I'd prefer all upper or all lower), but I would hardly make that a dealbreaker. -- Dirk _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
