Can you detect this error?

josh

I wrote something like the following code, and it resulted in a bunch (thankfully only several dozen) of records being corrupted. This kind of error can't happen in other language I have used. I was wondering if SRP or the OI compiler could check for this? I have VNAV checking on.

validate: if 1 then return valid = 0 end return

In case it's not obvious, the problem is that I am assigning a variable after the return statement. It should be before.

DonBakke

Syntactically there is nothing wrong with this code. I certainly understand the problem it created for you. I'm not a fan of using the return statement to force the end of a gosub like this, but it is valid.

I'm curious, what specifically couldn't happen in another language?

KevinFournier

@DonBakke, I know the Visual Studio compiler would have made the "value = 0" line faded and then warn you that everything after the return statement won't run. I think @josh is hoping that we would be able to add similar code analysis to the SRP Editor to help find subtle mistakes like these.

@josh, as an expert in language compilers, I can tell you that BASIC+ makes detecting things like this a chore. Revelation doesn't provide any services to break down the language into a formal syntax tree, and writing one for a language like this is not easy. I've tried, for fun, a couple times. Once we can break down the language into a formal syntax tree, we can start to do analysis like this, but we are talking months of work. Given our work load, I'm just not sure when such a feature can happen.

Don't get me wrong, I would love to have something like this, along with other things like inline errors, better code complete, smart autofill dropdowns... the list goes on.

josh

Ok, I am not demanding that you do it. I was just wondering if there was a setting I needed to turn on to get this error detection. I can live without out.

@donbakke
" I'm not a fan of using the return statement to force the end of a gosub like this, but it is valid."
Really, so you must have very nested code, which is hard to read and understand.

DonBakke

Really, so you must have very nested code, which is hard to read and understand.

Not necessarily. There are ways of avoiding "very nested code". The best way is to modularize code so that it isn't one big wall.

That said, I would rather read nested code that has a singular exit point than code that just prematurely aborts. For me, the latter this is much harder to follow and debug. I admit that I probably am in the minority in this view.

KevinFournier

@josh, you didn't come across as demanding at all. I was sincere in saying that I would love to have these kinds of features for BASIC+. BASIC+ in particular is a very flexible language, which lends itself to both more power and more room for mistakes. A solid code analysis system would help mitigate the latter.

Alas, if only I had more hours in the day. :)

As for the return statement... this is a long standing debate in the programming world. One camp insists on one Return per block, others insist that you should return as soon as possible for performance reasons. I straddle both fences. In BASIC+, I don't like multiple returns, but in C#, I'll often have several in a routine.

MattCrozier

That said, I would rather read nested code that has a singular exit point than code that just prematurely aborts. For me, the latter this is much harder to follow and debug. I admit that I probably am in the minority in this view.

I'll back you up on that, Don ;). Having one point of exit allows you to define and have better control of the exit conditions. Especially important as the code evolves in future development, with more variables and exit condition to cater for. I'll admit to on rare occasions using a GoTo straight to end of the routine where exit conditions can be dealt with.

DonBakke

I forgot to mention that having an ultra-wide monitor makes it easier to read nested code. I'm not endorsing the practice, but it is less of a problem reading the code compared to what we had "back in the day".

josh

It's not necessarily that the code is "wide".
It's that two logically connected pieces of the code (the then and the else clauses) are written far away from each other. In other words, it's hard to know what then clause an else clause is connected to if the else clause is separated from the then clause by lines and lines of nested code.

AusMarkB

It's that two logically connected pieces of the code (the then and the else clauses) are written far away from each other. In other words, it's hard to know what then clause an else clause is connected to if the else clause is separated from the then clause by lines and lines of nested code.

I think you'll find everyone is in agreeance on this point. That's the meaning of Don's earlier comment

The best way is to modularize code so that it isn't one big wall.

DonBakke

@josh - that is a fair point and I have experienced that problem. However, as @AusMarkB noted, this is usually avoided through modularized code. I'm willing to admit, however, that not all code can be constructed so nicely.

That said, usually when I find examples of Return statements being littered through out code, it isn't to avoid the "nested code" dilemma, but rather to avoid the need to add a few more lines of code to maintain a single exit point. That is, it is purely for convenience.