Dialyzer doesn't warn about this coding pattern when I run it, and I'm somewhat partial to the way it is now. It's not much of an issue in this particular statement, but when we have nested case/try/if clauses it can be difficult to figure out the possible values that the variable can take if it's only assigned outside the whole code block. I don't think I've ever seen coding conventions that express a preference one way or the other. Maybe I missed them. If dialyzer does warn about it we should definitely change it. Best,
Adam On Jan 31, 2011, at 6:07 AM, Robert Dionne wrote: > Thanks Adam, > > I also had broken up 988 to move some into 902 and the rest into 462. I'll > rearrange things based on this commit. > > One question I have is about a re-factor I did in 988 involving multiple > assignments to a variable[1]. This re-factor does nothing to change the > behavior of the code. Dialyzer does throw a warning about it, which is what > motivated it but I also think the re-factor is clearer and slightly more > readable as "Conflict" is assigned in one place. I've seen this before so I'm > wondering whats the preference on this. > > Cheers, > > Bob > > > [1] > https://github.com/bdionne/couchdb/commit/49bcb6df05dfefdcee40fea3d0fcded2859b6bf1#L0L30 > > > > On Jan 30, 2011, at 7:50 PM, Adam Kocoloski wrote: > >> I'm tired of waiting for the JIRA maintenance window to end so I'm just >> going to comment here. I've combined pieces of Bob Dionne's various patches >> from this ticket and COUCHDB-988 into a single commit here: >> >> https://github.com/kocolosk/couchdb/commit/1efd87 >> >> It focuses on the merge code/tests/docs. The actual change to the merge >> code is small and has been discussed before; I only replaced "or" with >> "orelse". The rest of the commit involves reorganizing and augmenting the >> tests and providing a version of Paul's description of the key tree as the >> module @doc. I think it's high time we get this into trunk. Best, >> >> Adam >