On Fri, Aug 28, 2009 at 11:49 AM, Duncan Murdoch <murdoch@stats.uwo.ca>wrote:

> On 8/28/2009 12:33 PM, Kevin Wright wrote:
>
>> On Fri, Aug 28, 2009 at 11:10 AM, Henrik Bengtsson <hb@stat.berkeley.edu
>> >wrote:
>>
>>  Quite a while ago I put up "R Coding Conventions (RCC) - a draft", now
>>> at:
>>>
>>>  http://docs.google.com/View?id=dddzqd53_2646dcw759cb
>>>
>>> It's useful for beginners and those coding "randomly".  Like it or not.
>>>
>>> It's ok to try to persuade people coding randomly, but otherwise it is
>>> waste of time to get into arguing over if-else or bracketing - we all
>>> have our own favorite.
>>>
>>> /Henrik
>>>
>>>
>> No, it IS not a waste of time.  I have wasted considerable time due the
>> lack
>> of a standard.  Yesterday I was debugging panel.levelplot and found this
>> code:
>>
>>    if (x.is.factor) {
>>        ux <- sort(unique(x[!is.na(x)]))
>>        lx <- rep(1, length(ux))
>>        cx <- ux
>>    }
>>    else {
>>        ux <- sort(unique(x[!is.na(x)]))
>>        bx <- if (length(ux) > 1)
>>            c(3 * ux[1] - ux[2], ux[-length(ux)] + ux[-1], 3 *
>>                ux[length(ux)] - ux[length(ux) - 1])/2
>>        else ux + c(-0.5, 0.5) * minXwid
>>        lx <- diff(bx)
>>        cx <- (bx[-1] + bx[-length(bx)])/2
>>    }
>>
>> You can't step through this because the "else" block starts on a new line.
>>
>
> In your other message you were talking about the browser.  Does it really
> have a problem with this (which would be a bug), or are you basically just
> cutting and pasting?
>
>  So you have to manually evaluate the value of "x.is.factor" to determine
>> if
>> it is TRUE or FALSE, scroll down to the line below "else" and continue
>> stepping through the code.  Try not to forget to accidentally evaluate the
>> last brace or do something else that kicks you out of the browser and
>> forces
>> you to start all over again.
>>
>
> Now that doesn't sound like the browser.  Whatever debugger you are using
> has a bug.
>
> Duncan Murdoch
>
>
Ah, right you are.  Thanks for the clarification.  This is not a "browser"
phenomenon, but due to using "ess-eval-line-and-step" (which is a kind of
cut and paste, I guess) to go through the code in emacs.  (Maybe there's a
better way?)

In any case, using "} else" eliminates the problem.

Kevin

	[[alternative HTML version deleted]]


