Over the years, I have played quite a few computer programming languages. ANSI C has become my top choice for ‘serious’ software projects, due to its small size, efficiency, flexibility, and ubiquitous support. Moreover, C is a mature language, with a rich ecosystem. As it turns out, C has also been consistently rated as one of the most popular computer languages (#1 or #2) over the past thirty years.
Needless to say, ANSI C has its own quirks, and it takes a steep learning curve. However, once you get over the hurdles, the language serves you. I cannot remember when, but it has been a long while that coding in ANSI C is no longer an issue. It is the understanding of scientific questions that takes most of my time, and coding helps greatly in refining my thoughts.
Not surprisingly, ANSI C was chosen as the sole language for DSSR (and SNAP, or 3DNA in general). The ensure the overall quality of the DSSR codebase, I have taken the following steps:
- The whole project is under git.
- The ANSI C source code is compiled with strict GCC options for full compliance to the standard:
-ansi -pedantic -W -Wall -Wextra -Wunused -Wshadow -Werror -O3
- The executable is checked with valgrind for any memory leak:
valgrind --leak-check=full x3dna-dssr -i=1ehz.pdb -o=1ehz.out --quiet ==19624== Memcheck, a memory error detector ==19624== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19624== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==19624== Command: x3dna-dssr -i=1ehz.pdb -o=1ehz.out --quiet ==19624== ==19624== ==19624== HEAP SUMMARY: ==19624== in use at exit: 0 bytes in 0 blocks ==19624== total heap usage: 52,829 allocs, 52,829 frees, 92,878,578 bytes allocated ==19624== ==19624== All heap blocks were freed -- no leaks are possible ==19624== ==19624== For counts of detected and suppressed errors, rerun with: -v ==19624== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
- Extensive tests (with the simple
diffcommand) to ensure the program is working as expected.
The above four measures combined allow me to add new features, refactor the code, and fix bugs, without worrying about accidentally breaking existing functionality. Reading literature (including citations to 3DNA/DSSR) and responding to user feedback on the 3DNA Forum keep me continuously improve DSSR. Some of the recent refinements to DSSR came about this way.
