Rename minPosts and maxPosts in min/max section

[mhmda-83]

I think this parameters name violate "Avoid context duplication".

[tobua]

Agree, personally I would also like minimum/maximum more in order to keep consistency with the "Avoid contractions" rule stated earlier.

[thekabal]

min/max as mentioned previously, and "prev" is also a contraction.

[kettanaito]

This is an interesting point. While avoiding contractions is a great default rule, I find certain terms to be rather natural when contracted. This is very likely to be a personal familiarity and not objectivism speaking.

The issue I see with maximum and minimum is their verbosity, which would contradict the "keep it short" point in here. The thing is that min and max may have roots in mathematics (let me know if that's the case), and even in their contracted form remain intuitive and descriptive.

The "avoid contractions" rule is here to apply to cases like ftchUsr where contractions decrease descriptiveness and are anything but intuitive, or using e as a variable name (not descriptive, not intuitive, but short, yeah).

Perhaps, we can mention in the contractions section that there are certain naturally contracted terms like mix/max/prev. Different languages may have their own natural vocabulary, which does not guarantee that those contractions make sense.

So, what do you think about mentioning "natural contractions"?

[tobua]

@kettanaito Thanks for the update. I agree that it's a good default rule and in my opinion and as described below one people should always stick to. In practice, it's largely about finding a sweet spot between contradicting rules.

In my experience, there is a natural tendency towards "keep it short" and to use abbreviations on repeated use and familiarity. It's easy to forget that many users might be unaware of what the abbreviation means and will have trouble finding out. Making variables longer on the other hand might lead to a slight decrease in performance but unlike abbreviations no real issues.

A good example are Jest matchers or the vitest API which contain very few abbreviations and some very long matchers like toBeGreaterThanOrEqual which is often abbreviated as just gte. Noted exceptions are toBeNaN and vi.fn, the first based on an existing abbreviation of the language and the latter probably to avoid use of a reserved word. As far as min and max are concerned I agree that these can and should be used as pretty much anybody knows them. prev on the other hand I think requires some familiarity. Even min can be mistaken as an abbreviation for minute. Since the goal of this cheatsheet is to find rules of thumb, I would recommend not to introduce natural/popular contractions and just stick with recommending to abstain from any contractions and apply keep it short to other things like unnecessary stuff or repetitions.

Language itself is constantly evolving and unnecessarily long words will disappear or be replaced naturally. Even though it might seem so, I don't think there is something as natural contractions.