13

As per Add data.SE style "magic links" to comments, currently, some help link require the help/ prefix while some don't:

  • [ask], [answer], [mcve], [tour] don't require it.
  • [help/on-topic], [help/dont-ask], [help/behavior] require it.
  • other help topics seem to not have a magic link to them at all.

I have been thrown off by this dichotomy numerous times since there's absolutely no indication which syntax I should use for which link, and if it even exists. In many cases, I gave up guessing (remember that you can't preview comments, so can't see if you guessed the syntax right until you post it) and resorted to a normal link instead — which defeats the purpose of having these magic links in the first place.

As such, I suggest to make a consistent syntax for all help pages that would be easy to guess:

  • the names should be equal to those of help pages to be deducible
    • the most used ones (in my SO practice, that's [ask] and [mcve]; a data.SE query could identify these objectively) may retain the short aliases as an alternative.
  • all should either be with or without the help/ prefix (save for the aforementioned short aliases perhaps).
    • AFAICS, none of the help article names clash with other magic links, current or potential, so, strictly speaking, there's nothing preventing using them without the prefix. This will also be consistent with the aforementioned short aliases if they are going to stay.
    • I don't strictly insist on no prefix though if the concern for future name clashes is just too great

An alternative solution may be a general syntax like [/help/<page>] for links (either to help pages or to any page on the same site) that would set link text to that page's title. It doesn't really matter what the specific syntax and implementation will be as long as it's consistent and deducible.

Improve this question
3
  • 2
    There's no reason why both can't be supported so that people familiar with the current implementation aren't affected by changes.
    – user1228
    Aug 30, 2018 at 14:54
  • @Won't Actually, there is a reason: multiple competing standards without a clear winner add disorder and confusion and introduce unnecessary choices to make (also add to maintenance costs but that's a lesser concern). That's why I only made an exception for the most used and the shortest ones since they are clear winners for high use case thanks to brevity. (I'm not insisting on dropping the current standard, only showing a potential drawback.)
    – ivan_pozdeev
    Aug 30, 2018 at 16:58
  • 1
    That reason doesn't anywhere near apply to this situation. There is no risk to maintainability or readability of comments.
    – user1228
    Aug 30, 2018 at 17:06

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .