- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
My new co-worker begins to replace GOTO in our programs with LINK.
I modified some of our existing programs to get rid of all the GOTO but not using LINK.
I test ran and compared the results to the production and they matched.
However my boss and his boss are forcing me to learn LINK and use it because my co-worker insisted on using LINK and nothing else.
Should LINK be recommended to replace GOTO ?
Minh
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
If it was up to me, and there was working code that used GOTOs and someone wanted to spend the time and energy and resources to replace the GOTOs with the LINK statement, I would say not to bother, I don't think this creates enough benefit to offset the cost.
Now perhaps at some company or university somewhere, there is some sort of push to standardize code so that they all do the things using the same methods, and GOTOs have become forbidden, then maybe its worth doing, but I'm still on the side of not doing it. If you are going to ban GOTOs, and you are going to spend the time and money and resources to get rid of them, then replace them with structured code, don't replace them with LINK statements.
The one place where I feel LINK statements are useful, is if you are writing a very long complicated data step, and in a dozen different places you have to perform the same mathematical calculations that takes (let's say) five lines of SAS code; then you don't have to put those five lines of SAS code in each of the dozen places, you can use a LINK there, and have the five lines of mathematical calculations in one place only (which has the added benefit that if you fix/enhance these mathematical calculations you only have to do it in one spot). But you haven't said this is the usage of the LINK command that your co-worker is using; and so in most other situations I would not use LINK.
Paige Miller
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I assume we are discussing DATA steps here.
I don't think the purpose of LINK is identical to the purpose of GOTO, and I can envision some programming situations where GOTO will work but LINK will not, and many other sitautions where either GOTO or LINK would work. Having said that, if you write structured code, you generally don't need GOTO commands but you might need LINK commands.
Paige Miller
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
GOTO is a symptom of unstructured thinking. Anybody who has to resort to it (and its slightly less abominable cousin LINK) simply lacks the necessary way of thinking that makes a programmer.
In the 1000+ programs I am responsible for there's not one of either.
My .02$.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
@MinhT wrote:
Hello,
My new co-worker begins to replace GOTO in our programs with LINK.
I modified some of our existing programs to get rid of all the GOTO but not using LINK.
I test ran and compared the results to the production and they matched.
However my boss and his boss are forcing me to learn LINK and use it because my co-worker insisted on using LINK and nothing else.
Should LINK be recommended to replace GOTO ?
Minh
Depends on how you were using the GOTO statements.
The LINK statement is for subroutine calls. So the block of code that is "linked" ends with a RETURN statement so that control will return back to the statement after the LINK statement.
If you are using two GOTOs to implement a subroutine call then you should replace them with a LINK instead since it will match what you are doing.
In general you shouldn't use either, although I have seen some solutions where it made sense because it was important to execute the exact same statement (not just another copy of the same syntax). But even then I bet there might be ways around it.
People like to equate GOTO with unstructured (or spaghetti) code. But in reality you can generate unstructured code without them and structured code with them. For example someone recently posted a macro that really violated my definition of structured. Instead of structuring the code to have one entry point and one exist point had what seemed like an exit point every two or three lines.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
@MinhT wrote:
My codes have no GOTO. I got rid of GOTO but not by using LINK.
So then what is the issue? Someone is replacing code that has zero GOTO statements (that's your statement) with LINK statements? I'm not sure I understand.
Paige Miller
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
My co-worker replaces existing codes that have GOTO statements with LINK statements?
My question is should LINK replace GOTO be recommended?
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
If it was up to me, and there was working code that used GOTOs and someone wanted to spend the time and energy and resources to replace the GOTOs with the LINK statement, I would say not to bother, I don't think this creates enough benefit to offset the cost.
Now perhaps at some company or university somewhere, there is some sort of push to standardize code so that they all do the things using the same methods, and GOTOs have become forbidden, then maybe its worth doing, but I'm still on the side of not doing it. If you are going to ban GOTOs, and you are going to spend the time and money and resources to get rid of them, then replace them with structured code, don't replace them with LINK statements.
The one place where I feel LINK statements are useful, is if you are writing a very long complicated data step, and in a dozen different places you have to perform the same mathematical calculations that takes (let's say) five lines of SAS code; then you don't have to put those five lines of SAS code in each of the dozen places, you can use a LINK there, and have the five lines of mathematical calculations in one place only (which has the added benefit that if you fix/enhance these mathematical calculations you only have to do it in one spot). But you haven't said this is the usage of the LINK command that your co-worker is using; and so in most other situations I would not use LINK.
Paige Miller
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
There are circumstances where using LINK statements calling subroutines in SAS DATA steps are justifiable. That is where you are doing complex simulations or algorithms and isolating and organizing repeated tasks into subroutines makes perfect sense.
The number of times I've done this I could count on the fingers of one hand. It's nice to have this functionality available for the very rare occasions where using it is the best approach.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
If performance is an issue, then it is better to define a macro for repeatedly used code.
Why?
The macro will be resolved only once while the data step is compiled, and at runtime there are no jumps and returns (which will need extra CPU cycles because of pushing return adresses to the stack and popping them back out).
That's why C coders rather use preprocessor definitions instead of functions; the executable will grow in size, but performance is noticeably better.
Granted that this may not be such an issue with SAS (I haven't tested this, as I have never used a LINK), but it may be stuff for contemplation.