I wrote about something similar to this (called "type-named objects") in a post last year[1]. The idea is that for small utility methods, you shouldn't have to interrupt your main flow of thought to come up with names for your formal parameters; in fact, you shouldn't even have to name your locals. If you're working in a language with a (perhaps already verbose) static type system, you can just leverage that.
So, for example, instead of this:
appendNode(node: Node): void {
this.tail.next = node;
this.tail = node;
}
... you can do: appendNode(Node): void {
this.tail.next = the Node;
this.tail = the Node;
}
This does introduce some precedence/binding gotchas that I go more into. But that hints towards further improvements. From the aforementioned post, you could end up with a language that allows: the ControlMessage's id := defocus
Or, if you add support for "passive voice" to your language: id from the ControlMessage := defocus
Completely unrelated, but related to the use of "the", Carmack wrote a tweet[2] that I've got embedded in the comments of a project of mine.> I have moved to naming global singletons with a The* prefix -- ThePacketServer, TheMasterServer, TheVoip, etc. Feels pretty good.
Since then, I stopped creating "proper" singletons altogether. Instead, it'd be a quasi-singleton, where I write a `MasterServer` class, and then bless an instance as `TheMasterServer`. Application code will always import, refer to, and otherwise operate on the latter, but tests are free to instantiate their own. This is especially useful if you have implemented some sort of developer switch in the UI that allows you to launch an embedded test harness within a live, running instance of the app. In that case, you don't exactly want your tests to be fiddling with your "real" singleton.
1. https://www.colbyrussell.com/2017/02/16/novel-ideas-for-prog...
2. https://twitter.com/ID_AA_Carmack/status/575788622554628096