BookmarkSubscribeRSS Feed
HeatherNewton
Quartz | Level 8

Hi I am looking at a lot of sas programs I realise whoever wrote it keep changing the case of the data set name or variable  name. e.g. one line the data set is in all capital letters and the next few data set below it was referred to with small letter instead.

is this some kind of common coding practice where case kept changing by programmer  for certain sense of readability etc,, I wonder please enlighten me

7 REPLIES 7
Kurt_Bremser
Super User

The most important thing is the consistent use of indentation to identify logical units in code (DO-END, SELECT-END, etc.), and the consistent use of empty lines (e.g. between steps). Spaghetti code severely reduces maintainability.

Take every opportunity to make code layout consistent.

AllanBowe
Barite | Level 11

We created a linter, which can enforce a series of best practices on SAS code.  There's an article on it here:  https://communities.sas.com/t5/SAS-Hacker-s-Hub/Hacker-tip-5-Linting-SAS-Code/m-p/801098#M125

 

Over time, with the help of the community (or as our organisation grows, through projects and sales of Data Controller), we will enhance and improve this library.

/Allan
SAS Challenges - SASensei
MacroCore library for app developers
SAS networking events (BeLux, Germany, UK&I)

Data Workflows, Data Contracts, Data Lineage, Drag & drop excel EUCs to SAS 9 & Viya - Data Controller
DevOps and AppDev on SAS 9 / Viya / Base SAS - SASjs
ballardw
Super User

Not claiming to be a "best practices" expert.

 

Code indentation I would say is more helpful than worrying about case except in displayed text like Format values, Titles, Footnotes or variable Labels.

 

For example, I have lots of data step code that originated as Proc Import code. Which will use a lot of upper case. I'm too lazy to change all that. But will use lower case versions of the variables for the code I write.

 

Occasionally I will use mixed case if I am sharing code so that the variable may be a little bit more self explanatory to someone else on the project. Otherwise variable LABELS carry the burden of describing the contents of variables.

 

Personal peeve is coding in proportional fonts and "bold" or "italic" fonts or anything that affects the amount of space individual characters occupy. A monospace type font makes it much easier, IMHO, to align code for parallel structures.

SASKiwi
PROC Star

There is no standard as such, it is usually down to individual programmers' preferences.

 

While most SAS users code in lowercase, there is a strong argument that mixed case improves readability. Imagine trying to read a book that is printed entirely in lowercase. Personally I've started to limited mixed case, especially for table and variable names. Frequently SAS reads external databases where tables and columns are usually defined in mixed case. It makes sense to keep that the same once imported into SAS. Consider this:

  • mylongcolumnname
  • MyLongColumnName
  • my_long_column_name
  • My_Long_Column_Name

Which do you find more readable?

 

Quentin
Super User

Would agree with others, this type of inconsistency is not good.

 

While there is no accepted best practice for a SAS coding style, I think the important thing to strive for in a programming style is consistency.  If you use a style consistently, the reader's mind will identify patterns and use them to help interpret the code.

 

As an example, in most cases SAS doesn't care if you use single quotes or double quotes.  I had a macro language teacher who said he always uses double quotes, unless there a reason to use single quotes.  His argument was that this made his code more ready to be macrocized (macrofied?) in the future, since macro tokens don't resolve inside single quotes.  And also that when you were reading his code, if you saw single quotes, they communicated an unusual intent: 'I am using single quotes here because I do not want any macro tokens in the string to resolve.'

 

Having two different styles in the same program can also be informative, if unhelpful.  e.g.  could be a sign that the code was written by two different people.

 

Personally, I'm probably too inconsistent in my use of single quotes/double quotes.  And also in my use of lowcase/PropCase. But I still see value in consistency. : )

The Boston Area SAS Users Group (BASUG) is hosting our in person SAS Blowout on Oct 18!
This full-day event in Cambridge, Mass features four presenters from SAS, presenting on a range of SAS 9 programming topics. Pre-registration by Oct 15 is required.
Full details and registration info at https://www.basug.org/events.

SAS Innovate 2025: Call for Content

Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!

Submit your idea!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 7 replies
  • 1127 views
  • 4 likes
  • 6 in conversation