Rick, I understand the point you are making in your post, but respectfully disagree with some of your points. For quick, ad-hoc purposes; many of the code short-cuts you outline above are perfectly legitimate. However, for large, complex production routines, these types of code practices can be extremely problematic. As one of the masses of SAS developers who have had the unfortunate task of having to unravel SAS routines developed by others for maintenance, enhancements or more often the case, to correct a fundamental flaw in the routine, these 'shortcut' coding practices can and often do case problems. Many of the problems I've had to solve in routines were related to these 'shortcut' coding practices because the developer(s) did not fully understanding what/how this might affect the rest of their logic. Instead, they make incorrect assumptions that a ";" here or there makes everything OK. Another issue and again, generally with larger, more complex routines is simple readability. I truly applaud some of the SAS gurus who can condense extremely complex data logic into a single statement...but often times, it falls on someone else to have to maintain it later.

Again, this is just my opinion, but I believe there's something to be said for solid coding practices that adhere to basic standards (e.g. use a RUN; statement after each DATA Step; include COMMENTS, etc.) and develop for maintainability and readability.