13 Conclusion

13.1 Benefits of offensive programming

Neither exhaustive nor limitative list. Main benefits are

  1. Applicable to new and legacy code
  2. Code instrumentation at the required level, according to your needs. No obligation to comply completely or to instrument completely.
  3. Transient or persistent approach allow to deal with code you own and code you do not own.
  4. Evaluation modes eases incremental work. Offensive programming type_checking_enforcement mode is complimentary of standard R evaluation mode, not contesting with it.
  5. Usable at build time, at test time, and at run time wherever and whenever needed.
  6. Reusable test cases, immediately available to replay. No need to read manual pages to run a test case. No need to type or copy/paste code to replay a test
  7. Allow industrialization of test cases
  8. Allow fully automated generation of testthat test cases
  9. Allow fully automated generation of R documentation

Most of all, offensive programming brings following value

  1. reduced code size, as many checks are no more necessary and shall no more be implemented
  2. higher developer’s productivity on R implementation, although earned time is varying greatly from function to function, depending of its complexity. I got more than 15% of time gain using offensive programming coding on several R package creations.
  3. Automated test case generation reduces greatly the burden of testthat content generation. Expect a productivity gain higher than 70% here.
  4. Documentation creation is now reduced in a great proportion, leaving just the review at your charge. Expect a productivity gain higher than 80% here.
  5. increased execution speed, due to reduced and simplified code. Again, many checks are no more necessary, and comparing, some traditional R code with offensive programming R code, will bring a clear value in favor of the second, as it tends not only to reduce the volume of code, but also to simplify your R code and to ease bug avoidance. The root cause of these two improvements is coming from type purity.

13.2 Concerns of offensive programming

Again a neither exhaustive nor limitative list

Non standard evaluation is always tricky and difficult to understand and put correctly in action, due to the two evaluation paradigms that are different from traditional R logic. Offensive programming is to be used wherever R standard evaluation scheme appears too limited or too lazy.

The two extraneous evaluation paradigms might bring runtime performance issues, especially if you compare with standard R evaluation. Indeed, doing so is unfair, as it is not comparing apple to apple. Offensive programming adds two more kind of checks to be run to decide on result compliance, that are simply unknown from R standard evaluation scheme.

Offensive programming requires some experience with it to fill comfortable in design, build, and run. Nevertheless, quite simple and intuitive, from a programming point of view. One piece of advice, be sure to have a clear idea of what you expect. In standard R, we are all used to get results without even asking ourselves any question about types, polymorphism, parameters and computed results. With offensive programming you must be able to answer clearly to such questions.

13.3 Your feedback is welcome

Your feedback about package usefulness, package usage, and package extensions is welcome, as any improvement suggestion.Share them, this will really help me.

I you wish to contribute to package development, just drop me an email.