Plain and simple, it will save you hours of debugging time. There are many mistakes which you can make when writing R:BASE code which are very time consuming to find. Some of these mistakes cause problems only intermittently. Some only cause problems when your code is codelocked. Sometimes the editors we use introduce subtle errors which do not show on the screen but can confuse R:BASE. The list is endless.
Developers who have started using R:Style tell us they would never want to be without R:Style again. We venture to say that R:Style saves at least a couple of hours a week in debugging time.
First of all, R:Style checks the structure of your code to make sure you have balanced quotes, parentheses, IF/ENDIF, WHILE/ENDW, etc. These are all problems which should be fixed before the code is run or traced. It is a lot faster to R:Style a new or modified piece of code, than it is to run the code. It literally takes a few seconds, R:Style is blazing fast. Structural inconsistencies are the kind of problems that cause TRACE to act weirdly or bomb completely. R:Style reports code errors with their line numbers so you can find and fix them quickly. The error report goes to the screen, but the output can be redirected to a file or printer. Only the part of the screen display which you need for debugging will be redirected. This is especially helpful the first time you run your code through R:Style, as there is likely to be a large list the first time.
Secondly, TABS and other hidden characters embedded in the code (except in quoted strings which R:Style protects) can cause erratic behavior of your code in sometimes unpredictable ways. They are difficult for a programmer to find but easy for R:Style to scrub out. Because R:Style can cleanly reformat code to a style pleasing to you, the scrubbing actually will enhance the way your code looks. You have a raft of styling options to achieve this goal.
R:Style finds problems that we are tripping over all the time. It will actually teach you to write cleaner code as you see the errors it flags. In addition, following its advice will make your code more compatible with future versions of R:BASE, which always seem to get less tolerant of non-conforming code.
