Supporting your research project

• An Output is any material a researcher wants to remove from their SRS project to outside of the SRS platform.

• An Ingest is any material a researcher wants to add to their SRS project from outside of the SRS platform. 

• A Transfer is any material a researcher wants to copy from one SRS project to another.

Researchers wanting to Output, Ingest, or Transfer any work from their Secure Research Service (SRS) project, will need to prepare the files for action, complete a request form, and submit a request to the SRS. 

The 'Instructions and Guidance for Output, Ingest and Transfer Requests' document (available in 'Related downloads' at the top of this page) provides detailed guidance and instructions on the processes.

Note that for all requests:

• All projects featuring in a request must remain 'live' (i.e. have started and not yet ended) whilst the request is being actioned.

• Only those named as a 'Researcher' on a given project are permitted to make such requests. 

• The SRS complete all researcher requests as quickly as possible, but we recommend that researchers submit requests as far in advance of requirement as possible.

When the research project is complete, we ask researchers to provide us with any final publications associated with the work. In some cases, we may seek to produce a case study where we see examples of innovative methodology, strong public benefit, or outstanding collaboration. Please see further details on the Research outcomes page.

As of 14 May 2024:

• Adobe Acrobat Reader DC
• Anaconda 4,4
• Python 3.7.6
• ArcGIS 10.4.1
• ArcMap 10.4.1
• Jupyter Notebook
• Microsoft Office Professional Plus 2021
• ML-Win (3.04)
• Notepad++
• Qtconsole
• R for Windows (3.6.1, 4.0.2, 4.3)
• R Studio (2022.07.2)
• SAS v9.3
• SPSS v29
• Spyder 4
• STATA (16MP, 17SE)
• Winzip
• MPlus 8 Demo
• SQL Server Management Studio
• Java Development Kit
• JAGS

Work on-going to upgrade to R 4.4 and STATA 18.

Code sharing exists to enable researchers to use code created by other researchers to improve efficiency and reproducibility, and sustainability.

Sharing code has many advantages, for example, researchers can build upon existing code, as well as enabling researchers to follow best practice and increase transparency.

Secure Research Service Code Library

We are currently building a library of user-contributed code within the Secure Research Service (SRS). Building this within a Trusted Research Environment (TRE) means that we must ensure code is safe to be shared with other users.

Code used for a number of tasks can be added to the library. Examples of these tasks may include:

• importing and exporting data
• transposing data
• cleaning data (for example, dealing with typos)
• validating data (for example, checking data types, checking that data fall within expected ranges)
• deriving new variables
• merging datasets

Your responsibilities

If you want to contribute code, please do the following:

• contact the SRS Statistical Support team, who can provide you with a link to fill out the relevant forms and documentation; all code within the SRS Code Library needs to be documented to comply with Digital Economy Act rules

• please ensure code is safe (not disclosive or malicious) before submitting to be shared; normal statistical disclosure control (SDC) checks will be applied to any code being shared within the code library

It is important to note that that the SRS Statistical Support team is not responsible for:

• ensuring the validity of statistical research or outputs using code from the code library
• ensuring code is fully functioning

Before submitting your code to us...

Please ensure that any code you wish to contribute is non-disclosive. This means that it should not contain any data or produce disclosive results (extracting record-level data). It should also not contain full file-paths.

Please check Section 4: Stata Quality Assurance checklist to ensure your code is of the best possible value to others.

The Statistical Support team will conduct normal SDC checks on any code submitted for the code library but will not consider other quality issues such as code accuracy or efficiency. If you have any questions please get in touch with the Statistical Support team.

Along with your code we need some documentation that tells other researchers what the code does.

Please submit a 'read me' file with your code, which provides other researchers with information about your code and what it does. 'Read me' files could set out how the code should be used, and any additional packages or data the user may need access to.

An example of a 'read me' file can be found within the code library in the SRS.

What happens after the code has been added to the library?

Once code has been cleared by the Statistical Support team it will be added to the code library, and you will be notified that this has happened. All researchers have access to the code library and can now use the code you have submitted for their research projects.

The Statistical Support team is not responsible for the correct working of the code. Sometimes code breaks because of software or package updates. If this is the case you can contact the Statistical Support team to submit any changes, which will go through the usual process of SDC checks. Please inform us if the code you are submitting is to fix or replace existing code in the code drive. The Statistical Support team will not contact you to request updates.

If users tell us code that was submitted no longer works we may decide to archive the code.

If you no longer want your code to be shared, please get in touch with the Statistical Support team, who can remove your code from the library. However, we cannot guarantee that no other users have copies of your code within their own projects as the SRS does not fully monitor which code is being taken from the SRS code library.

Adapted from the Quality assurance checklist from the quality assurance of code for analysis and research guidance.

Modular code

• Individual pieces of logic are written as smaller programmes.
• One main .do file runs the smaller programmes; this is fully annotated with sub routines listed.

Good coding practices

• Names used in the code are informative and concise.
• Code logic is clear and avoids unnecessary complexity.
• Code follows a standard style:
• variable names are lowercase_with_underscores (snake case) or follow another (named) style guide
• variable names are descriptive
• code is DRY (do not repeat yourself)
• code is kept as simple as possible

Project structure

• A clear, standard directory structure is used to separate input data, outputs, sharing code and documentation; other folders may be present, but those needed to replicate code are clearly listed in the README file.
• File names do not contain spaces, instead using underscores.

Code documentation

• Comments are used to describe why code is written in a particular way, rather than describing what the code is doing.
• Comments are kept up to date, so they do not confuse the reader.
• Code is not commented out to adjust which lines of code run.
• Code comments must not be disclosive in any way - for example, result returns 5, John Doe returned, and so on.

Project documentation

• A README file details:
• author Information
• the purpose of the project (About the Project)
• software dependencies (including versions)
• basic installation instructions (if required)
• file requirements:
• main script files
• dependent datasets are listed
• required passwords, secrets and tokens are documented
• instructions for how to cite the project are given
• the code must have a disclaimer - for example, "This code is developed by the <>; errors, omissions and coding decisions are the responsibility of the team."
• where appropriate, guidance for prospective contributors is available including a code of conduct

Configuration

• File paths are removed.
• Configuration is written as code and is clearly separated from code used for analysis (Global Files in STATA).
• The configuration used to generate particular outputs, releases and publications is recorded.

Data management

• Input data is versioned; all changes to the data result in new versions being created, or changes are recorded as new records.
• All input data are documented in a data register, including where they come from and their importance to the analysis.
• Datasets used are clearly listed in the README file.

Dependency management

• Required add-ons are documented, including their versions in the README.
• Example configuration files are provided (Global files in STATA).

Logging

• Misuse or failure in the code produces informative error messages.
• Code configuration is recorded when the code is run (Global files in STATA).

You can contact the Secure Research Service (SRS) Customer Support team for more information by email srs.customer.support@ons.gov.uk.

If you require initial log on credentials or a password reset, please contact by telephone on +44 1329 447871 between the hours of 9am and 11am and 1pm and 3pm.