Good Programming Practices, Writing Clean Code, and Winning Over Your Teammates

Are we losing the art of writing clean code? Programming is not just logic, it is an art form. Regardless of the industry we are coding in, code is often maintained and reused by multiple programmers. Heck, even your future self, 6 months down the line, might be left scratching your head wondering what you were thinking during development. I know I've written code (with comments) that probably made sense at the time, but struggled to re-interpret months or years later, ... guilty!  

Code is hard to read and digest. It's even harder when we were not the original developers of the code and there are no comments. I don't know many programmers that enjoy taking over programs from others. If I had to guess, its likely due to the pain and agony of reading, deciphering, and understanding another's program. If we dig deeper, it is often because the code does not adhere to good programming practices. I work in the pharmaceutical industry where we write data set and output programs to create clinical trial summary reports. We often reuse programs from other clinical studies that were carried out in a similar manner or have collected similar data. Adhering to good programming practices is important and this article is a reminder to myself, as I've notice my own programming practices starting to slip.

For the pharmaceutical industry, Phuse has published a Good Programming Practices guidance here, https://www.phusewiki.org/wiki/images/d/d4/GPP_Guidance_Document_v1.1.docx

If I had to pick one above all others, it is the comments. Modularizing a program with section comments breaks up the code into smaller digestible segments. For example:

*************************************************;
  Reading in Source Data
*************************************************;
proc sql;
  ...
run;


*************************************************;
  Summarizing Data / Statistical Modeling
*************************************************;
proc means data=adsl;
  ...
run;

proc freq data=adsl;
  ...
run;


*************************************************;
  Combine Results
*************************************************;
data final;
  ...
run;


*************************************************;
  Produce Output File
*************************************************;
proc report data=final missing split="|";
  ...
run;


*************************************************;
  End Program
*************************************************;

It can greatly cut down the time one needs to locate the piece of code that needs updating. Adding additional, single line comments, for each PROC, DATA step, and complex code provides even more direction and guidance for the consumer of our programs.

When we write clean code, it is not just for us and the task at hand, it is for the person reusing and updating our code (or even your future self). We give that person confidence that we care about our art form (our coding craft). Not only does that signal we did our job to the best of our ability, but that we also cared enough about our teammates adopting and reusing our programs. I don't know about you, but that's someone I would like to work alongside.

I'd be interested to hear in the LinkedIn comments, what is your most admired good programming practice.