10 October 2024¶
Eamon Conway: coding tools and workflow¶
In this meeting Eamon gave a presentation about a range of coding tools and how he makes use of them in his workflow.
Attendance: 3 in person, 5 online
Info
We welcome presentations about research projects and experiences that relate in any way to reproducibility and good computational research practices. Presentations can be short, informal, and free-form.
Please contact us if you have anything you might like to present!
Linters¶
Key message
Linters enforce a consistent coding style, which makes it easier to read your own code and also other people's code.
Eamon began using linters to format his code in order to avoid creating commits that contained "noise" such as trailing space characters at the end of a line and other unanticipated minor effects. One source of motivation was working on Git is my lab book, which is written in Markdown.
You can adjust your editor settings so that it will automatically format your code whenever you save, whenever you paste text, or even whenever you type (which some people suggested might be annoying!).
Michael mentioned that when working on shared R code with Eamon, who isn't an R coder, he used lintr and styler to clean up Eamon's code and make it easier for him (Michael) to understand.
Michael also asked if anyone had good experiences when edited nested code blocks in R Markdown documents. Rob replied that he uses Emacs, and that polymode handle nested R code blocks very smoothly, but he has no experience with other editors — and doesn't suggest anyone switch to using Emacs!
Language servers¶
Key message
Language servers are tools that understand your code and can make your editor more powerful.
An immediate question from the audience was: "what is a language server?"
A language server is a program that understands your code and provides your editor with features such as:
-
Automatic completion of variable and function names;
-
Displaying documentation when you place your cursor on a variable or function; and
-
Renaming variables and functions in every file that uses them.
Nick mentioned that ark is a language server for R.
It's created by Posit and (at the time of writing) is only available in Positron.
Rob said that he uses python-lsp-server for Python, and basedpyright is another language server for Python.
Nick asked how Eamon (and others) have set up language servers. Some editors support language servers through separate packages or extensions (e.g., for VS Code), while other editors have a single "LSP" package that will automatically use any installed language server when you open a code file.
Eamon then walked through some examples of using language server features in VS Code, for both C++ and Python files.
Debugging¶
Key message
Stepping through your code is a great way to investigate when it doesn't appear to be working as intended
The discussion then moved on to using debuggers to step through your code, so that you can understand what it's doing when you think there's a problem.
In the examples that Eamon presented, he uses Python code as a "wrapper" to call his C++ code, and the debugger allows him to step from Python code into the C++ code and back to Python again.
Nick mentioned that he has used Positron to debug C code that was being called from R, using the LLDB debugger, and that it is also possible to step into Python code from R.
In fact, as Eamon explained, if your code is compiled with an LLVM toolchain, you can used LLDB to step through code that is written in multiple languages (e.g., C, C++, Julia, Rust).
This was followed by a broader discussion about VS Code, Posit, and R Studio, which features these editors provide, and which additional features can be enabled by installing additional packages.
Testing¶
Key message
Pick a testing framework and give it a go!
Eamon finished by talking about writing and running test cases, using Python as an example.
He showed how to use unittest, which is part of Python's standard library.
One feature that Eamon has found particularly useful is the ability to only run tests that are relevant to the current file or code that he's working on.
Eamon emphasised that testing your code is something you need to learn by doing, and told everyone:
Just pick a testing framework and give it a go! Most, if not all, of the concepts and practices will be directly applicable to other frameworks, if you end up finding a better tool.
For example, Rob mentioned that he uses pytest instead of unittest, because it is fully compatible with unittest but adds a lot of useful features, such as running tests that failed last time, and allowing you to select specific tests to run.
For R, testthat is the most popular unit testing package.
Nick mentioned that lazytest lets you rerun only the tests that have failed during the last run, and that usethis can create GitHub actions for automatically running your tests.
Automation¶
Key message
Using an automation tool to perform repetitive tasks can prevent human errors.
Eamon explained that he uses GNU Make to ensure that his C++ code is recompiled when necessary, so that the executables are always up to date.
The targets package provides similar functionality for R.
Importantly, both of these tools understand the dependencies between running commands/code and the files/outputs that will be created. This means that they know which files and outputs are up to date, and can avoid unnecessary computation.
Eamon asked if there is an equivalent or similar package for Python.