Stats from my last open source contribution:
lines added: 79
lined deleted: 82
lines in commit msg: 870
I can't decide if I'm doing software development really _wrong_, or really _right_.
@codesections I guess unless it's Perl. In which case you probably just made it less readable.
Well, it's not quite perl, mostly
@codesections don't take my Perl hate personally. I've just had two bad experiences with perl and swore never to open a .pl file again.
:) Not taken personally at all.
Also, I should probably repeat my previous toot with better capitalization:
well, it's Not Quite Perl, mostly (https://github.com/Raku/nqp)
@codesections yeah I figured it was raku 😉
Truth be told I'm vastly under qualified to say anything about perl or derivatives. I probably just got some really bad code.
@codesections I've definitely written paragraphs to describe two lines of code. I've even started entire flame wars over changing one character in a line of code, preceded by buckets of words justifying said change.
It's times like that that I reflect on the nature of the "line" in our collective "lines of code" metrics.
> I've even started entire flame wars over changing one character in a line of code, preceded by buckets of words justifying said change.
care to share the story behind that one?
@codesections basically I made a PR in an open source project correcting a decade-old mistake. In a giant commit of changes, someone had accidentally set a range to be -1-1, when it was supposed to be 0-1 (as seen in the commit before). This mistake went unnoticed until I found it again.
Problem is, this was in a pretty core part of the codebase, so reverting it back to the correct range would trigger a huge cascade of changes. So, they insisted keeping in the mistake in the name of backwards compatibility because it had been in there so long.
@codesections Helpful contributions are always right! :D
@codesections Reaaally right IMHO, even if it's just for the lines in commit messages.
Many a repo I browse online has commit messages that are only a slight imprevement over the hash of the commit itself. Personally I stick to detailed commit messages even in my dotfiles and esp. for less important changes because that's just the kind of thing you'll forget why you did the day after.
@codesections shrinking the code size is always good.