Consistent Code

[RobertASmith]

Hi Nathan,

Suggestions for the consistent code section...

• I would be less concerned about a specific style guide (e.g. Tidyverse), but more concerned about general good coding principles. The structure of the code is probably the biggest thing (i.e. not having long lines of code doing multiple things, not hard coding values into functions etc).

• NICE could provide an example which others could follow, a model that has been coded using 'best practices'. It could also push back on submissions that are deemed 'too messy' to review.

• I think the use of 3rd party packages is a separate issue, and one that could feature in a really interesting paper. I think this should be a separate section. I personally think the way forward is for a group (maybe NICE DSU) to get funding to review health economics packages - the review would be of both the code (although this can be done by other organizations at cheaper rates) and the underlying methods. Collaboration with data-science/software engineering groups may be beneficial. The fact that the code is on CRAN (alone) is not evidence it is methodologically robust (although packages that have been tested extensively and are not health economics specific may be trusted, for example we are not going to test ggplot).

• I would also include a section on functions. Keeping functions defined in a separate folder called src/R would be beneficial - these should be understood in isolation & well commented.

P.S. I am very keen on your compendium of health economics packages. I think this will be super-useful going forward.