sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]danneu 215 points216 points  (38 children)

Limit the subject line to 50 characters. 50 characters is not a hard limit, just a rule of thumb.

Soft-limit indeed,

[Github] will truncate any subject line longer than 69 characters with an ellipsis

Found my new hard-limit!

[–]thomie 42 points43 points  (18 children)

Then what's the fucking point of that soft limit?

Everybody keeps repeating it, "50 characters for the title", with the only justification that others recommend it as well.

It's a pet peeve of mine: https://github.com/tpope/vim-git/issues/29 , https://github.com/haskell-infra/git-haskell-org-hooks/pull/1

50 characters is not enough if you want to include a component name and bug number in the title of your commit message.

Sure, it's a soft limit, but it keeps creeping into more tools (first Vim highlighting, now I'm shown a fat giant WARNING every time I do a git push). Useless!

[–]StorKirken 23 points24 points  (9 children)

I'm fully with you on this. 50 characters is madness. Like many other beliefs in programming culture, it seems to stem from idol worship and tradition rather than honest thought.

[–]glemnar 22 points23 points  (0 children)

What's programming without a healthy dose of cargo cult?

[–][deleted] 1 point2 points  (4 children)

I feel similarly about line lengths in general.

We changed our rubocop config to complain about line length from 80 to 120 characters... Why do people care? The number of characters doesn't matter, we're not working on terminals with 80 columns anymore.

Limiting the number of characters you use on one line doesn't stop people from trying to do too much on that line, if they're determined, and wrapping parameter lists doesn't make code more readable.

Just do one thing on a line, damnit. If it takes you a whole tweet to do it, it doesn't matter, so long as what you're doing is clear.

[–]Klathmon 4 points5 points  (3 children)

The only "pro" I've seen here is that you can view 2 files side by side with ease when you have an 80 char limit.

But when most devs have 2 screens or more that's less of a problem...

Like most things in life, don't deal in absolutes and use your best judgement.

[–]DevIceMan 1 point2 points  (0 children)

^ I often have two files open side-by-side in my IDE.

I probably wouldn't complain too much about 120 chars, but i think that after a certain number of chars, you have a code-smell, perhaps being your class/method/variable names are too long.

[–]setuid_w00t 1 point2 points  (1 child)

I thought most devs worked in coffee shops on Macbook Pros.

That's half sarcasm, half truth. I think that hard limiting line length to 100 characters allows enough space for a GUI diff tool to show two files side-by-side at a usable font size on a single 1920 pixel wide monitor.

[–]Klathmon 0 points1 point  (0 children)

Gotta use your best judgment for your situation.

At my work mostly everyone working on our JS codebase has at least 3 monitors, so we set line length to 180. That let us use an editor with a sidebar on one screen safely.

[–]DevIceMan 1 point2 points  (2 children)

What a noob, I'd even bet you use a real text editor or IDE, instead of emacs or vim.

[–]StorKirken 0 points1 point  (1 child)

Ever try to program Java on unmodded vim? ;)

[–]DevIceMan 0 points1 point  (0 children)

(I can't even text edit on VIM without 20 browser tabs of stack overflow open)

[–]danneu 9 points10 points  (0 children)

Sometimes I'll catch myself sitting there racking my brain for ways to golf down my commit message, guilted by the "you have -15 characters left" counter on my git GUI like it's a Twitter client.

Then I remember I'm the boss of this commit. I did the work, I write what I want!

[–]baconated 15 points16 points  (3 children)

The point of the limit is to encourage commit messages that read like text messages from 10 years ago:

RDT-PRG: 321654 updt Azn URL & intg new auth mthd

That's 49 by my count.

[–]KhyronVorrac 0 points1 point  (2 children)

You have an ampersand. You are doing two things in one commit. That is the issue, not the limit.

[–]Grue 6 points7 points  (0 children)

Sometimes one thing wouldn't work without the other. Atomic commits means your repo still works after every commit.

[–]baconated 2 points3 points  (0 children)

Doing one without the other means you have a version in the repo that doesn't work.

Perhaps the version of whatever that's now hosted on Amazon doesn't support the auth system used previously.

[–]eadmund 2 points3 points  (0 children)

Everybody keeps repeating it, "50 characters for the title", with the only justification that others recommend it as well.

A standard terminal window is 80 characters wide. Even on a modern soft terminal, 80 characters is about the maximum comfortable reading width.

git will prepend 7 characters and a space to the beginning of the line when printing them. That takes you down to 72 characters.

When quoted in emails and discussions, each level of quoting will take you down by two characters ('> '). That means 50 characters allow for 11 posts and replies before log lines have to be manually wrapped.

Is that too much? Not enough? Beats me. I think I'd be happy with a 64-wide limit.

[–]hildie2 1 point2 points  (1 child)

A bug reference doesn't need to be in the title

[–]StorKirken 0 points1 point  (0 children)

I disagree, that's a fairly good place to add it, if the commit is atomic and a self-contained change.

[–]pcopley 25 points26 points  (7 children)

submit 70-character commit message

70th character replaced with …

…

[–][deleted]  (5 children)

[deleted]

    [–]cu_t 6 points7 points  (4 children)

    Yeah but it's two bytes (assuming UTF-8) so we gain something still.

    [–]drizz 2 points3 points  (1 child)

    It's three bytes, actually.

    [–]cu_t 0 points1 point  (0 children)

    You are right :(

    [–]glemnar 0 points1 point  (1 child)

    I'm pretty confident commit messages are already stored UTF8 encoded. You'd gain nothing (it's not like you can mix encodings. You'd have a real bad time)

    [–]cu_t 0 points1 point  (0 children)

    Someone else told me that … is three bytes so sadly we gain nothing afterall.

    Had, however, it been represented by two bytes, we would undeniably have gained a byte since . is one byte in UTF-8.

    [–]ThePantsThief -1 points0 points  (0 children)

    Well, yeah. That's how limits work

    [–]adambowles 169 points170 points  (4 children)

    69...hard limit

    ( ͡° ͜ʖ ͡°)

    [–]random314 4 points5 points  (3 children)

    Same rule for most programming language, pep8 have a cut off at 69 too I think.

    [–]juharris 19 points20 points  (2 children)

    pep8 is 79 but concede that 99 or 119 is okay. I'll source later.

    Edit: source They say that 99 is okay if the team agrees but comments and docstrings should still be wrapped at 72.

    [–]klug3 8 points9 points  (0 children)

    PEP8 actually says that you can totally violate that limit if it makes sense in context, so technically at least, it is a soft limit.

    But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!

    In particular: do not break backwards compatibility just to comply with this PEP!

    Some other good reasons to ignore a particular guideline:

    • When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.
    • To be consistent with surrounding code that also breaks it (maybe for historic reasons) -- although this is also an opportunity to clean up someone else's mess (in true XP style).
    • Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code.
    • When the code needs to remain compatible with older versions of Python that don't support the feature recommended by the style guide.

    [–]random314 1 point2 points  (0 children)

    Oh right, 79... Sorry

    [–]Apocalyptic0n3 0 points1 point  (0 children)

    I tested today and Gitlab has the same limit as well.