Hey bud bud, I hope you are enjoying the sunshine and summer time wherever you are.
Today I would like to talk a bit about 'Naming' things from a general sense to a more specific sense and focusing on Naming Conventions used in programming, and hopefully provide an abstracted method on doing it in the right way.
But first, there is a story I would like to share, so gather around the fire pit my friends...
How not to name a pet...
Many, many moons ago, when this bear was a lot less fuzzier, I had the pleasure of sharing a den with some of the best people I have ever lived with. Good friends, and even better living companions. Life was fun, we were all young, care free.
We had a new den-mate had just move in only migrate back home for the summer break. Summer-times, when, let's call her 'Alice' went on her annual migration tours would be an all boys affair.
We would take advantage of baring our chests more on the hotter days, and generally being messy boys. Dishes would often take all off the counter space before they would be considered for washing...Pizza box forts, more fermented vegetables and fruit juice than actual fruit and veg, oh, and plenty of Xbox-live.
When Alice, moved in, my other den-mate lets name him "Oliver" had kept a pet rat, it took some adjusting but it was fine, 'Eva' was a white albino rat, and was very well trained.
Alice had a small ginger little weirdo of a hamster that she kept from her previous den. Now this hamster had no name, no identity apart from being called 'The Hamster' and was a bit touched in the head.
With Alice away for some time, me and a friend, were enjoying a Rastafarian themed day, at this point we were indeed on our way to Zion, and the innocuous question came up: "Why doesn't The Hamster have a name?" to which I replied, "Alice, didn't want to get too attached with it, really she brought it to spite her ex, it's more like forced custody"...
Given the mood that we were in, this was quite funny. Just the mental picture of a hamster, being used in a custody battle in was enough to set us off for a while.
Once we came too, we started brainstorming names for the hamster, things like "Rico, Gizmo, Wacko, Pablo" - there were many suggestions, till the list of sanitised words began to run low, and we started to play what was an impromptu form of "Pet Names against Humanity"...
Now I do wish to keep this somewhat kosher, but suffice to say some of the suggestions didn't make it past the cutting desk... I mean this was before the whole PC culture exploded and even at that some of the suggestions was just to far for us, which is really a statement.
The name we ended up settling for was "Feltchy" now I have included a link to the definition of the term for those who may not know of such a things, oh how precious you are 🙄 .
Upon settling this name the hilarity only got compounded further when I had texted her with the announcement that her hamster formally known as 'The Hamster' was rechristened as "Feltchy"...(Alice is Irish-Catholic) 😆
Thing was she was at dinner, with her extended family. I don't know why she thought about telling her dad ( who is an actual legend), whom then decided to tell her young niece of the hamsters name, who then proceed to ask her dad what feltchy meant at the dinner table...🤣
Ah to be a fly on the wall, we did enjoy the tsunami of angry texts messages that was sent back from Alice. She was in her words, 'not amused' 🤦♀️
Oliver and I decided to affirm the name by only referring to the hamster to Feltchy at all times. He even started to train it to responding to the name, which was even better.
For when Alice came back, the damage was already done. Alice only relented to the fact after she unwittingly was feeding it and talking to it like she did (turns out Feltchy wasn't the only weirdo in the den), and in-order to coax it out of its home, she would be calling out 'Hamster' when this didn't work, she sighed and defeatedly uttered "Feltchy" and the little lovable ginger psycho came waddling out of its home.
Feltchy lived a long life, and became a strange fixture in the den but one that had his place. RIP little bud.
So that is my story on how not to name a pet...In a sense Naming stuff is an artform in itself. You can either bit a generic, non-descript, beige, unimaginative name like 'The Hamster' or you could pick a name that has some flair like 'Feltchy the Hamster'.
This plays out in other facets of life, for the names or labels that we place on things are purposely created to convey the value of the thing just from acquiring name itself, its intuitively simple yet its amazingly overly complicated.
Naming Conventions
I keep seeing this brought up in many online forums and places when learning more about computer programming,
"There are only two hard things in Computer Science: cache invalidation and naming things."
I am not going to pretend for a second that I know enough about 'cache invalidation' but naming things, is something that I think is a slightly easier concept to get to grips with.
Before I circle back to naming stuff in Computing, I would like to explore how other real sciences tackle the same problems in their respective fields.
Within the scientific field of Chemistry they're set standards for naming compounds. Sets of rules for coming up with names for compounds and practically everything else chemistry related.
These are set on high by trusted, reputable institutions that govern the rules for all to obey. In the field of Chemistry this is done by the chart topping boy band "International Union of Pure and Applied Chemistry". Their rules applies to everything! From the organic to inorganic compounds, temperatures, units, etc.
The Chemical Nomenclature is a systematic method used to derive the technical names for the very stuff that chemists talk about and use on a daily basis. It allows for little to no ambiguity over the compound, its structure, or form.
So something like Acetylsalicylic acid, or 2-Acetoxybenzoic acid; which is Aspirin. Or Trichloromethane or Chloroform. These often long and convoluted names along with their more colloquial terms are all governed by strict rules set by IUPAC.
In Biology, there is a whole field dedicated to just naming things. Taxonomy is a wonderful process which determines the classification of the plethora of organisms that exists in the many different kingdoms.
Within the field of Taxonomy there are taxonomical structures to determine the names of the different kingdoms, classes , orders, families and then their subsequent genus and species.
Science is all about strict governance, by having strict governance when applying the adequate labels that describe our organism or compound we can convey with little effort, information about the thing that we are working on.
To broaden the scope here a bit further. Linguists such as Noam Chomsky, who work and help define the language by studying it, came up with this grammatically correct sentence, that has no meaning. A grammatically correct sentence that means nothing
"Colourless green ideas sleep furiously"
He argues in his works "Syntactic Structures" that syntax and the study of it was independent to the study of semantics, which means sentence structures and their meanings are isolated from one another.
Keeping with the spoken languages, in France, there is an actual body that regulates and controls the French language.
Known as the Académie Française, which is made up of 40 high profile individuals with the best job title ever! "The Immortals", you might ask why do the French feel that they need to have a body that regulates the French language? Well this goes off-piste but suffice it to say its more to do with making sure the French are and forever will be French, more than anything else.
The same can be said about a number of other different languages, my other favourite example is that of högsvenska or High Swedish. Until recently Sweden had about 3 different languages that became prominent in different parts of Scandinavia. It wasn't til '09 when a new language law was implemented in Sweden making Swedish the main official language, before that the swedish language wasn't really popular with the nobility and the elites of the Swedish society. However, it is often considered that if your literary skills could be conveyed into High Swedish, you are a pretty dam skilled wordsmith.
My point, is that to have strong naming conventions, you need to have strong governance over that particular language. Strictness is embedded into the very foundations of syntax and speech. Its why we all hate the members of the Self Appointed Grammar Police Force.
Computationally Speaking
However, in Computing and in programming more generally this strict governance towards naming conventions in languages is almost lost, since it is not practiced by many, in equal fashion.
In light of saying that statement, some form of governance in the many interdisciplinary programming languages, does exist, to some extent.
After the superficial surface of the field this breaks down into forms of governance that is similar to either that of chieftains and tribes or local PTA meetings.
Given the variety of the different programming languages out there, wishing for a Single Governance Model is akin to wishing for the grand unified theory in physics to exist or hoping that the second coming happens in your lifetime. I mean out of the three, you'd stand a better bet with the last one.
So we then have to hope that these languages have their own set governance model, and naming conventions that we can follow and adhere too. Helping to reduce the ambiguity and hence the overall complexity that is required, or better known in the industry as 'mental overhead' ... (Just on another note, developers should really stop adopting the language of business managers, them dullards love coming up with new compound words and jargon phrases every other time they load up MS Word.)
In the realms of web development we have three main languages that we work with.
- HTML
- CSS -JavaScript
Let's explore the governance models around each of these languages first.
HTML
HTML is the oldest out of the three, since its inception, it has had 5 fundamental and structural changes.
The first draft of the spec was released in June 1992 it then had seven subsequent revisions, only for HTML 1.1 to be released later in November of that year. In June of 1993 HTML language was published by the Internet Engineering Taskforce, (who sound like a fun bunch to go drinking with, just not down at the ports...)
Only for it to be pulled and replaced by a second version a month later, the first real solid draft of the language came out in 1995 by this point it was called HTML 3.0. One of the many big earthquakes of the 90's.
By mid 2011, HTML had matured enough to issue a 'Last-call' to its community to 'confirm the technical soundness of the specification'. Meaning it had at last matured enough to be considered solid.
Now we are going through the period called HTML5-The Living Spec. Where can deliver more accurate semantic meaning to our elements. Combining both the semantic meaning behind the <div>, so more devices including those that use assistive technologies could get more value from the information that it encloses.
Within HTML there's a respectable, stable institution driving the specification and the changes that come from it's maturing into a complete language that we work with today.
The role of the World Wide Web Consortium (W3C), headed by Sir Tim Berners-Lee, guided the creation of both HTML and CSS into standards that are unambiguous. Well up until you read the spec doc itself...
In HTML lies two particular fields that are at the heart of all of this. class and id. Here we are left to our own imagination when it comes to creating names, and boy do we have an imagination.
CSS
In the world of CSS we have standards that relate to the style rules and their implementation, what don't we have are the set conventions over is the naming of our classes for the styles we wish to implement.
A couple of quick google searches would bring up a list of varied ways to go about naming your styles, these are:
- BEM : Block - Element - Modifier 🙂
- SMACSS : Scalable and Modular Architecture for CSS 🤔
- SUITCSS - Structured classes CSS 😑
- OOCSS - Object Orientated CSS 🤨
- AMCSS - Atomic CSS 😣
Personally I use the BEM standard convention. This is a far more practical and applicable method of deriving class names that would save on confusion, and if I am communicating it to someone else, allows for clarity and clarification most importantly confers value.
The BEM method is simple and straightforward to understand and can easily be implemented into your work style, on any type of stylesheet.
<a href="somewhere.com"
class="link-external
link-external-hover">
It goes like this say you have a Link element to an external page and we wish to give it an effect when it is hovered, using the BEM convention. We would have two classes, one that affects the element in its natural state, and one when it is modified to hover. This would lead to class names such as: link-external & link-external-hover. link is the block, a lexical pointer to the <a> tag, external is the element in particular.
.link-external{
//Styles goes here
}
.link-external-hover::hover{
}
For we could have several different types of Links on our site and we don't want to affect them all. hover is the modifier, you can argue that since :hover exists as part of the CSS pseudo selectors why not just apply that to the .link-external, I would say, the point is to convey that the element would have a class that works when it is hovered, instead of nested away inside the stylesheet.
There is a simplicity to this method, by having the focus work down from parent to child to whatever it is we are changing or what it is we are modifying we can help us structure a suitable methodology that we would apply to our own holistic unorthodox naming convention.
Just to recap
Who do I belong to - What am I targeting - What am I wanting to do with it
or
Block-Element-Modifier
JavaScript
JavaScript in comparison to the monarchical setup of HTML and CSS being under the tutelage of Sir Tim and the W3C, is more of a hostile landscape of feudal barons, city-states and roaming warlords.
In all fairness to JS, it did have a torrid childhood and upbringing. Being 25 years old, its slower to mature than the other two, partly because of its origins hampered it's growth somewhat, or perhaps it just took it longer to go through puberty, who knows, all I can do is present why our beloved JS is such a basket-case.
In the the mid-decade that made all the best music, there was a bit of a rebel for the lost cause named Brandan Eich, he worked for a small and not so important web browser company called, Netscape, they didn't last long.
In about 10 days he managed to craft a programming language that worked with the browser and allowed programmers the ability to do some extra stuff, giving their small and not-so-significant company a bit of an advantage in the now infamous 'Browser Wars',
Originally the Language was called Mocha, as in the crap you get from Starbucks. Then it became LiveScript, and since Java which is a completely different programming language at the time was getting a lot of notoriety, not at all jumping on the Java coat-tails, they rebranded to JavaScript....(this is a very clever business decision, that definitely stood the test of time).😶
Being conceived in ten days does make the early years a bit formidable, and it did have issues. A lot of them had to do with over complexity, overly verbose (like this post) major incompatibility issues between the different browsers that were becoming established players of the day.
At 2 years old, it was handed off by Daddy to its foster Mummy, the European Computer Manufacturers Association or better know as ECMA, who had the lovely goal at the time of trying to standardising computing.
Mummy did do a lot of work in the early years, given its adoption amongst the small pool of web programmers at the time, it was slowly becoming the de facto language of the web.
Towards the end of the 90's, Mummy had revised JS three times. Working on ECMAScript 4, then, JS hit the torrid years.
Wanting to do things that other languages could do like generators, destructuring, anonymous functions, classes, etc. This caused puberty to go on for about 10 years. Scared with acne, voice deep as a bass drum, and about 6'2'', our lad had grown up somewhat.
By 2008 after a lovely family consolidation holiday in Oslo, ECMAScript 4 was finally resolved, a lot of issues was worked on in Harmony and by 2015, our wee kid had became a man, and somehow finished uni, now he was looking to make a stamp on the world with ECMAScript6 (ES6).
Since then we have had annual additions to the ECMAScript standard, so at 25 years JS is now on the ESNext standard...which is super awesome,
You might be wondering, but there is governance in JS, its got Mummy, and Mummy has been good for it, I mean, he's turned out no bad for a bastard.
True, Mummy has done a splendid job making the language work better.
But...
During the years that JS was growing up, there were alot of support from the community. Taking the load from Mum at times, in terms of development. In all honesty they are still the drive behind the language to be so ubiquitous as it is today.
A key driving force from the community was the introduction of frameworks and libraries such as JQuery, AJAX, works by groups like CommonJS helped to push JS to go outside the browser, once it escaped, JS went everywhere and can be used practically everywhere.
The pace of frameworks and innovation from the community had outstripped the pace of JS and Mummy. This is why there is so many different ways of doing things in JS, from Callbacks to Promises to Async/Await, Mummy had a lot to do.
Coming up with a standard naming convention was the last thing on her mind. Given that other languages had some manner of a naming convention for its users to name attributes and the assumption was that that you know developers would incorporate the same over, was an assumption to far.
Two things, one we are placing to much credence on other languages having a stronger governance model. The other, is that coming up with names to describe semantic html or descriptive css class names is something that with a bit of practice is relatively easy to adopt.
So why is it the second hardest thing to do after cache validation?
Readability
I have to say, I find that JS has really matured to a point where you can code in close to English as possible and still have it execute.
This is something that I thoroughly endorse, where the programming lexicon and the english language are interchangeable.
Code, should be read like this blog post, easy and straightforward with little to no cognitive overhead as possible.
To steal a coin from my old chemistry teacher,
"Write your lab reports as if someone else who has no clue what to do, can do what you just did"
I feel that this should apply to all aspects of coding, including documentation.
Readability is very important when it comes to reproducing code, it is even more cogent when creating your own code.
Having code that is difficult to read, or indeed having authors who write overly long books with never ending storylines, is more than a hindrance. It's a time killer, in a time-sensitive world. Every minute counts.
So how does one come up with a formula of sorts for creating names that way they don't have to spend eons deciphering code using ruin stones , sheep's blood and a ouija board.
How about, BEM but for JS
using the same concept as earlier when using BEM to apply class names we can get a bit more specific and detailed, with our names. This again, lets us confer the value of the function or object that we are working with. Saving on mistakes and namespace clashes.
What I propose would be something similar to this:
JS Reserved Term prefixBlock-Element-Action/Modifier-Type
const usrGetData = async()=>{}
const lblSignInText = () => {}
const btnSubmit-handler = () =>{}
export function btnSignUpSubmit-util(){}
The role of the prefix is important for grouping blocks and roles together.
Element describes the part of the block we are targeting.
Modifier terms that can describe the Action of the code block.
Type is residual, this can refer to something like Obj,Class,Utils etc.
Reading code should provide an eagle eye overview of what is doing on without getting to lost in the details and the mechanics.
There are a few rules when it comes to writing code capable of being readable and the most important one is the name.
If you can't describe what it does, you don't know it well enough....
Being able to describe something in a short, succinct and structured way is probably the only thing I can say is the golden rule when it comes to any form of a naming convention.
Enlightening as that was, the essence of which translates into a descriptive code base whether it is written declaratively or imperatively is irrelevant.
If the description fails the term then there are two failures going on, one to the coder, cause if you can't describe what it does, who could? And perhaps the greatest disservice is felt by the next person having to read your code.
The Fuzzy Way
So that's the situation, and from the sounds of things, JS is not an isolated situation, but JS is a basketcase of a programming language, let's not be kidded.
The Fuzzy Way basically requires some extra considerations to be made when we are coding,
Rules that would keep us right as we batter away at the keyboard all day and all night.
1) Eligible > Illegible Can you explain what it is you are doing, if not none else will be able to.
2) Code != Cute Don't get cute with code. If you can try to avoid it, sometimes cryptic one-liners are not necessary.
3) Simple > Complex > Complicated Simpler, Smaller chunks of code is better than Complex bits of code, which is still better than Complicated Code.
4) Explicit > Implicit Better to be Explicit in your definitions and explanation than Implicit, don't make the reader infer your intentions. Both Humans and Machines cant read minds...
5) Simple != Stupid Keeping it Simple is better than Keeping them Stupid.
Wrapping it up
This post became way longer than I intended, I do apologies, but I do hope you managed to take away a better understanding on how to go about naming things
The way of the Fuzz, is more of a philosophical approach to solving some of the problems when it comes to having standardised naming conventions in programming in particular JS. There is more, I might put it down on paper.
Albeit I strongly advocate the use of strong governance, and in a language where its DIY or DIE, having something is better than nothing, for that I suppose there is TypeScript.