coding best practice

[HeatherNewton]

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

[Kurt_Bremser]

The common accepted practice (see the posts by senior users here - Super Users and Proc Stars) is to use all lowercase.

[Kurt_Bremser]

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]

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.

[ballardw]

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]

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?

[Kurt_Bremser]

You may find it funny, but I like option 3 best.

[Quentin]

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. : )