Длина скрипта SAS и рефакторинг - PullRequest
1 голос
/ 13 октября 2011

Я унаследовал сценарий SAS длиной более 37 000 строк, не включая дополнительные унаследованные модули.Учитывая начальные знания SAS и умеренное знание Python, мне было интересно, считалось ли это чрезмерным, как мне кажется, и рекомендациями по способу наложения и разбивки типичного сценария SAS.

Спасибо

Ответы [ 3 ]

4 голосов
/ 17 октября 2011

Это общая проблема с SAS, так как многие люди, которые пишут программы SAS, имеют опыт анализа и неэффективного программирования.Первое, что я хотел бы предложить, это поместить блок кода в определение макроса, затем протестировать вызов макроса и завершить программу оператором ENDSAS, прежде чем он выполнит остальную часть кода.Это позволит вам запустить диагностику, чтобы определить, что делает этот блок кода.Как только вы поймете, что делает код, вы можете решить, хотите ли вы разбить этот код на дополнительные определения макросов, чтобы каждый макрос выполнял один логически сплоченный набор инструкций.

Оказавшись в программе, вы можете найти похожиеКод повторяется с некоторыми отличиями, такими как выбор параметров, имен наборов данных или переменных.Если вы обнаружите этот тип повторения, вы, вероятно, сможете разработать макрос, который использует параметры для обобщения кода.После этого вы можете заменить повторяющиеся экземпляры вызовом макроса, изменив параметры по мере необходимости.

Аналогично, с таким длинным сценарием я бы ожидал, что вы найдете место, где вставка цикла DO поможетдобавить структуру, независимо от того, находится ли она в определении макроса или в шаге DATA.

Иногда, тем не менее, программе SAS просто требуется столько строк кода.Разбиение его на логические этапы с определениями макросов поможет его удобочитаемости и удобству, но мало поможет повышению эффективности.В этих случаях, по крайней мере, вы должны написать раздел комментариев вверху, в котором кратко описывается цель программы, а затем добавить комментарии по всему коду, чтобы объяснить, что делает конкретный блок кода.

Вот два предостережения для этой техники.Во-первых, если исходная программа определяет макропеременные, то у вас может возникнуть проблема в области действия этих переменных, если вы определите их в макросе.Макропеременные, определенные вне определения макроса, имеют глобальный характер;но если вы не укажете, что они должны быть глобальными, то макропеременные, определенные в определении макроса (и параметры макроса, установленные при вызове макроса), будут локальными и не будут доступны после выполнения макроса.Аналогичная проблема заключается в том, что несколько макропеременных могут иметь одно и то же имя, но их область действия различна, что может привести к неожиданным значениям при их возврате.Второе предупреждение заключается в том, что если вы используете макроопределение для комментирования больших блоков кода, чтобы можно было протестировать последующие разделы кода в другом прогоне, то обязательно сохраните все необходимые наборы данных в постоянном месте;в противном случае они будут удалены и не будут доступны для последующего тестирования.

Удачи.

3 голосов
/ 19 октября 2011

Я считаю, что лучше размещать ТОЛЬКО ПОВТОРЯЮЩИЕСЯ блоки кода (или блоки кода, требующие обработки макроса) в% макроблоках. Если одного комментария может быть достаточно для описания цели раздела кода, то чаще всего это лучший подход.

Помещение кода в макроблоки, которые не связаны с обработкой макросов, просто запутывает простой код SAS. Это все равно, что обернуть существующую функцию в вашу собственную пользовательскую функцию, не добавляя к ней никаких дополнительных функций.

Наличие 37k LOC - это определенно чрезмерно (для одной программы), и я уверен, что большинство из них будут повторяющимися, поэтому ответ @ RWill все еще остается верным. Тем не менее, я думаю, что лучшим подходом было бы разделение кода на несколько файлов (каждый файл с определенной целью), которые затем можно вызывать с помощью оператора % include . Таким образом, вы можете избежать необходимости иметь много (потенциально) ненужных макросов и при этом сделать их более самодокументированными.

Приветствие Rob

2 голосов
/ 19 октября 2011

@ RWill делает хорошие предложения. Секционирование с помощью% макроблоков очень полезно для запуска кода за раз. Использование Enterprise Guide (я использую 4.3) также позволяет разбить код на части. Узлы кода могут быть созданы и связаны так, что программа может запускаться по частям за раз, или может выполняться вся ветвь. Кроме того, выходные наборы данных визуально связаны с программными блоками.

...