How to abbr guidelines

[T1xx1]

For the rules we will open a new issue to discuss them. Anyway, the syllable counting seems like an interesting approach.

Approaches

• half length of the word
• original word as to be at least 5 characters
• syllabus count

Originally posted by @kisvegabor in https://github.com/kisvegabor/abbreviations-in-code/issues/23#issuecomment-1385630800

[kisvegabor]

I think @philipeachille was right about these should be only guidelines and not strict rules as there can be exceptions.

[kisvegabor]

We should decide how to handle multiple possible abbreviations of a word. I think we shouldn't create another https://www.abbreviations.com/ but create a list where we recommend an abbreviation for words common is software development.

IMO it's important that :yellow_circle: is Context-sensitive and not a "not that good but might be used" abbreviation.

[T1xx1]

I think @philipeachille was right about these should be only guidelines and not strict rules as there can be exceptions.

Sure

[T1xx1]

We should decide how to handle multiple possible abbreviations of a word. I think we shouldn't create another https://www.abbreviations.com/ but create a list where we recommend an abbreviation for words common is software development.

We should reccomend the most used and mark all the others with :yellow_circle:

IMO it's important that :yellow_circle: is Context-sensitive and not a "not that good but might be used" abbreviation.

Yes

[kisvegabor]

So I mean we shouldn't list abbreviation just because they exist. We should pick the one, that we find the best. :yellow_circle: abbreviation are also recommended but only if the context is clear. Let me give an example: Vertical can be abbreviated as:

• v
• vrt
• ver
• vert

These all are valid but we say use only

• :green_circle: ver

and do not list the others as they are not recommended.

Or

• :green_circle: char (good any context)
• :yellow_circle: c (only if it's obvious that it's a character)
• do not list ch, chtr etc as they are no recommended

:red_circle: should be used for very common abbreviations that we don't recommend for some reason. E.g. cpy for copy is common, but not recommended as it's only 1 letter shorter.

[T1xx1]

So I mean we shouldn't list abbreviation just because they exist. We should pick the one, that we find the best. :yellow_circle: abbreviation are also recommended but only if the context is clear. Let me give an example: Vertical can be abbreviated as:

• v
• vrt
• ver
• vert

These all are valid but we say use only

• :green_circle: ver

and do not list the others as they are not recommended.

Or

• :green_circle: char (good any context)
• :yellow_circle: c (only if it's obvious that it's a character)
• do not list ch, chtr etc as they are no recommended

:red_circle: should be used for very common abbreviations that we don't recommend for some reason. E.g. cpy for copy is common, but not recommended as it's only 1 letter shorter.

Yes yes. We should keep only the green ones. Yellow only if they have a good context. Red, if are used in general but are wrong.

[philipeachille]

As this list has grown and seemingly more people look at it, it can become a guideline to projects and teams, rather than just some list to refer to. I do use this repo now as THE how-to-abbreviate. What's not in this repo is not abbreviated in my code until an issue is opened and the abbreviation decided on (like I did with "threshold").

So I agree with "We should pick the one, that we find the best". Therefore the yellow and red ones should be as few as possible

[T1xx1]

I think we should open an issue called Abbrs and make there all the discussion for new or current abbrs because if we open single issues for every abbr they will become a lot.

[kisvegabor]

Makes sense!

[philipeachille]

I don't see a problem with "if we open single issues for every abbr they will become a lot." I think one thread fro all will be a big mess and hard to follow quickly. Note that over time it will be less as more is decided upon

[T1xx1]

I don't see a problem with "if we open single issues for every abbr they will become a lot." I think one thread fro all will be a big mess and hard to follow quickly. Note that over time it will be less as more is decided upon

Same thing trying to connect different conversations in different issues. I'm expiriencing it also right now with the JSON issue. Infact I had to edit it and add links to all the abbrs before it.

[kisvegabor]

Or we can say that: let's focus on refactoring and formatting now and use the current "dictionary". After that we can think about the dictionary on a 1 PR/word basis.

What do you think?

[T1xx1]

Task