Suggestion: Add rationales for abbreviation selection

[emareg]

I think this list is great! :) However, I miss the reasoning or evidence why certain abbreviations are considered good or bad.

My suggestion is to state a set of rationales (R1 – Rx) at the top of the Readme and then refer to them with an internal link after each item.

For example, a rational would be “R1: Abbreviations that only save a single letter are inefficient and not worth the potential confusion”. That is why “usr” is a bad abbreviation and the entry could look like this:

• user • 🔴 usr (→R1)

Now the question is, should this also be true for two letter savings? This seems to be less clear as you have the following entries:

• class • 🔴 cls
• clear • 🟢 clr

From just reading the list, I cannot understand why clr seems to be OK and cls is not. I would like to have this reference to a rational and maybe a conflicting abbreviation or some statistics of how often a term is found in code.

[T1xx1]

Hi @emareg,

I think this list is great! :)

Thanks, me and the others are putting much effort into it, to make it the best.

---

However, I miss the reasoning or evidence why certain abbreviations are considered good or bad.

The abbrs themselves are not considered good or bad in fact, in the legend they are marked as recommended or not, this because some abbrs may be more appropriate for some codebases more than others.

We do state in the desc:
[...] your naming will become more coherent, logical and understandable to other programmers (even newbies).
That's kinda of our goal.

Some time ago there was another line saying:
The most important thing is to remain consistent in your code (do not mix *txt* with *text*).
Which I removed in this commit line 21

We're not judging how good an abbr is, but provoding a suggestion of which ones you should use instead of some others.
But that's totally on you to follow or not these suggestions

Even in this message if I would use abbrev instead of abbr you'll still understand what it means.
Abbr is shorter so it does win over abbrev (that's not much but still a gain).

Another example: many words could end up having the same abbr. They're marked red because if you find that abbreviation you'll probably not understand what it means at first glace or worse you could misunderstand the meaning.

Like

So we're not suggesting using that.

---

• class • 🔴 cls
• clear • 🟢 clr
  From just reading the list, I cannot understand why clr seems to be OK and cls is not.

Neither I do. That's not so clear because you find a conflict.
The only thing that comes to my mind to explain it, it's that maybe because in HTML you can't abbreviate the class attr so is not worth abbreviate it somewhere else but idk.
We're trying to be as coherent as possible but there're quite some abbrs now in this list (263) so some little conflicts sometimes just happens 🤣.

Btw thanks for the report/look up I'm going to find a way to fix that.

---

or some statistics of how often a term is found in code.

That's seems a good idea to provide more info to decide which abbr to use, but in my opition too advanced for a project which scope is just to provide a simple guide on abbrs.

Since kisvegabor created this project, I may have been the one changing the format many times and much from the beginning to make it more readable but was and is still just a list.

---

My suggestion is to state a set of rationales (R1 – Rx) at the top of the Readme and then refer to them with an internal link after each item.
For example, a rational would be “R1: Abbreviations that only save a single letter are inefficient and not worth the potential confusion”.

I haven't got that part quite right.
You're suggesting categorizing the abbr also based on some sorta subclass like the one that gives you word gain, am I right?

---

Hope I was clear even if I'm not a native English speaker.