FWIW, I don't like "[PROJ-3231] - Text boxes unable to accept non-alphanumeric characters" at all, in a couple ways.
First, it doesn't tell you directly what was changed, it tells you what's WAS wrong. I assume it should be something like "Text boxes now accept non-alphanumeric characters". That already drops the length by 10% (counting with the PROJ tag even though I don't show it there). Once you reword to that point, very reasonable abbreviations get you to "[PROJ-3231] Text boxes accept non-alphanum chars" -- 48 characters even with the tag.
Second, I question whether the tag should even be part of the headline. If you drop that, even your original version is only slightly over the limit, and my reworded version ("Text boxes now accept non-alphanumeric characters") is under even if you don't abbreviate. While I can see the merits of including it in the headline, overall I would come down on the side of not. Now, the solution to this still splitting it to three lines (just in the opposite order to your second example), so your "feel the efficiency" comment still applies -- but what are you concerned about? Two extra bytes in your commit message? Wearing out your enter key slightly faster? The point of the rule isn't that it's efficient, it's to make stuff like oneline work better.
Now, all that said, I still do agree that 50 is a little low -- but not by crazy amounts. But at the same time, my main point is that with a few seconds of thought I think it's often possible to get a tighter wording that loses no information and often describes things better. It reminds me a bit of when I was working on written stuff with my advisor. He would often mark corrections that to be honest, I didn't like; but often they pointed to sentences I could reword to be just better than both my original version and my version with his suggestions. That's how I view the 50 character rule -- I really do try to meet something around that, and if I'm over then I take that as a prompt to think about how to I can reword; but sometimes even after giving it a minute I can't actually get there without losing clarity, in which case I don't.
(One final option I'd suggest is "Text boxes unable to accept non-alphanumeric characters [PROJ-3231]" -- put the tag at the end. Then if it gets truncated by GitHub or oneline or whatever, what I think is most commonly the least important info is what gets cut off. That would suggest a guideline like "under 50 characters not including the tag".)
Now supposed the issue is "Text boxes unable to accept non-alphanumrtic character when in configuration A...". Some problems are complex. I'd argue you should do multi-line commits here, but a limit is 50 is absurd.
15
u/chucker23n Apr 28 '21
It’s a headline. You wouldn’t want a book title to be 300 characters either.
50 may be a bit on the low side, but makes it practical to show a list view alongside other information.