Naming philosophy (for Lisp stuff)

Abbreviations...

...and cryptic letter combinations, even numbers, are OK! Needs to contain at least one letter obv.

I’m just fine with kind of a C programmer’s approach to naming.

The names do not need to be long and descriptive if they are used often. (Conversely, they do if they are used seldomly.)

Precedent: cons, cdr, car, progn, list-ref

Examples: fn, strse, 7off, c, o

Hyphencase...

...a.k.a. skewer case is the way. All in lower case.

Precedent: with-input-from-file, list-ref

Example: define-ir-syntax

No new grawlix

By grawlix I mean non-alphanumerical seven-bit characters like < and }. Do not use them in your names.

Grawlix

Weird unicode stuff

I have no current plans to switch over from -> to → but I wouldn’t mind it if that change happened, consistently. Emoji names are fine too but since I found that they make my SSH sessions bork up I stopped using them.

Alphabet and numbers is OK, then anything else on the keyboard is not OK, and then unicode stuff above that is OK again.

If that sounds weird, there’s a good reason.

Computer programmers have had this weird tendency to reach for those character that actually have another meaning. For example, $ means dollars, money. But shell script uses it to mark a variable.

It’s this re-purposing of existing ASCII-matics that I wanna put the kibosh on.

Gladly use already-grandfathered-in grawlix

This includes for example

Parens

Quotes

Quasiquotation

Unquote

Unquote-splicing

String literals

Predicate question marks

Side effect bangs (although I can sometimes be sloppy on that one)

The -> convention, both at the start of, end of, or middle of names

Preexisting operators like > and * and +

Backslash escapes in strings

#\c style characters

* for variants

More recent stuff but reluctantly allowed include

The @ attribute marker in SXML

The colon at end of keywords or as used in SRFI-42

Basically all of SRE

Point is, I love quasiquotation. It’s pretty much the best part of Lisp, the fact that code is also data and data is also code. I’m never gonna let go of my weird commas, apostrophes, backticks and at signs in that context.

The purpose of the philosophy isn’t to go back and edit old code from

to

The purpose of the philosophy is to say “OK, this is fine but no further”. Completely arbitarily drawing a line in the sand at around year 2002 or so. Older than that is great, newer than that is clutter that I can’t accept, get off my lawn and what not.

I found early on that I was really tempted to kid myself into seeing my own new stuff as special and as worthy of using these overly grawlixy names. “This new operator is going to be absolutely foundational!”

But in hindsight everytime I’ve instead used a name based on hyphen-cased letters I’ve been happy about that. Because sometimes the new operators do become pretty foundational, like cut arguably has become, and then we’re stuck with all these ants-like weird characters crawling over our code.

Also lists shall use parens and not square brackets. Come on now.

Update

An older version had:

> Even more reluctant attitude towards

The slot syntax in SRFI-26.

But I haven’t had to use SRFI-26 since we made fn and c. I’ve ended up being very happy about fn; it’s lambda the ultimate combinator expressed more concisely and in plain letters. So it’s possible to become free from even something like cut.

fn and over