@hans was a typo, thanks for the catch; i have corrected it. ;)
I find myself agreeing with Mike W on this one in being generally in favor of (some) abbreviations, though I can certainly understand the "fully written out = easier to read (and thus maintain) code" argument.
I should also add: I have found I apply abbreviations inconsistently (Much to my internal engineer's chagrin)
s/set is an easy one and as mentioned, quickly becomes comfortable. I also tend to use d/do.
However, for control-flow items (for/if/while) i find myself always writing these out. After reading John's subcomment above, I wonder if indeed this could be related to the larger "semantic gap" that develops in (for example) parsing "f" vs "for" / "i" vs "if" - it is harder for NLP english brain to quickly internalize the true meaning.
One additional point touched on: preserving spacing. Abbreviations won't usually save vertical space, but I would contend that sometimes horizontal space (which they do save) is a premium as well. Lines running offscreen can be annoyance at best, but at worst can cause a programmer to misparse or even completely miss sections of code. For this reason, I will usually try to break long lines (ie, a long concatted string) over multiple lines with an indented "_". Abbreviating saves hspace as well - albeit moreso $ objs functions than commands.
Speaking of which... Wasn't asked by OP, but similarly for objs functions: I will almost always use $P over $Piece, $S over $Select (but not $C for $CASE 
). I can understand rationale for spelling these out but as these (especially some $S) expressions can get complex, I find abbreviating the func itself helps keep focus on the expression logic itself. Sometimes an extra space between parens can go a long way towards maximizing this clarity. Oh, and $ZDT >> $ZDATETIME any day :) Similarly, would anyone actually ever write $HOROLOG over $H ?
In a similar, related vein of "cautionary M tales" - found this lovely gem crawling some forums last year (from a much older post from the days where the Cache tech stack was perhaps a bit less mature) :
"The following is a valid line of MUMPS code:
A B:C D E F G=H:I:J K:L M N O,P Q:R S T=UVW X YZ
It means "Line is labelled A. Breakpoint if C is true. Do the E subroutine. For G=H to J, incrementing by I. If L is true, kill (unset) the M variable. Create new variables O and P. If R is true, quit. Set the T variable = the UVW variable. Execute the contents of the YZ variable as if it contains valid MUMPS code." I remember showing some code to a college friend when I'd been working with it for a few months, and he asked why my printer was spewing line noise."
From <https://what.thedailywtf.com/topic/508/intersystems-cach-233-gateway-to-hell/21>
Social networks
Has anyone ever converted an HL7-embedded Base64-encoded PDF TO (HL7-embedded) RTF?
This looks great, but i noticed the linked LibreOffice conversion table seems to indicate PDF can only be exported (conversion target), not imported (conversion source)
Honestly interested in PDF of any kind; "converting" B64 PDF to a flatfile *.pdf is trivial, but it looks like using *.pdf as a source is not supported for LibreOffice method?
FWIW: Ensemble v2016.2 on Windows