我希望大家记着：你是怎么样的一个人，过得怎么样，不需要别人来定义和评论；但是如果你自己都觉得自己需要改变了，那么你可能真的需要做些什么来改变自己了。
其实这篇文章也应该归属于SAS程序员的自我修养系列，但是不是那么具体，只是一些通用的习惯，并不是强制要求，但是根据我这几年的工作经验来说，养成这些工作习惯，对你日后的工作效率都有一些益处。
1：我们在写TS domain时候，很多TSPARAMCD\TSPARAM都需要从试验方案寻找（所以开始一个项目前，养成阅读试验方案的习惯，把一些关键的信息记录到项目文件夹里，可能对后面的编程有帮助），在写TS SPEC的时候，最好在后面加上这个TSPARAMCD来自试验方案的第几页，
有些文件在交付给申办方审核的时候，有些申办方会要求看你的SPEC，然后会核对你写的SPEC是否正确，比如写TS，有时候他们没找到试验终止的条例，需要你指出，这时候你查看你自己的备份，立马就知道这些条件在试验方案的第几页，而不是从头看试验方案，一个一个去找。
2：在写ADaM SPEC的时候，尤其是一些BDS数据集，需要创建各种各样的分析flag用于后面的TFL分析，如果不是你接着写对应分析数据集的TFL，那么其他人在调用这些分析flag的时候，需要一个一个去看对应的是哪张TFL，尤其是写ADLB相关的TABLE，对其他同事挺不友好的。所以，最好在创建分析FLAG的时候，在SPEC后面加上这个FLAG对应的是哪个TFL。你好大家好。
3:编程的时候，如果有一些特殊要求，这时候最好在你的程序上加上一些注释，注明为什么这样做，比如：
“2022/10/29：LSP和申办方沟通，说因为这个受试者属于特别受试者，即使没有用药，也需要纳入安全性分析（一般不这样，我只是举个例子）”
像肿瘤项目，研究时间长，可能患者入组后我们编程部门就开始编程了，之后会涉及好几轮dry run，时间跨度可能好几年，如果你一开始这样写程序，没有任何备注，那么过了一段时间，你再看你的程序，可能都不知道为什么当初这样做。所以，多加注释。
4：说到注释，如果你喜欢写宏，切记一定要写清每个宏变量的作用，写在你的宏程序里面，我不能保证你一直在这家公司工作，如果你离职了，后面其他同事接手你的程序，一大堆宏，没有任何注释，很痛苦！！！每个人的代码风格不一样，所以还是有好一点。
5：在写SDTM spec的时候，对于某个变量的值，一般会有一列CRF Page，记录这个值是来自aCRF上的那一页，你在写SDTM spec的时候，养成好习惯，写上去，不要写一段这个变量怎么衍生就是了，给LSP减轻工作量或者说规范点。
网友评论