Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Good Developers Write Bad Code: An Observational Case Study [pdf]

upedu.org

Post reply on HN
Print view View original

81–85 of 85 posts

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#81

Post by eterm »

omouse wrote: post #65
sanderjd wrote: post #48

Earlier quoted context omitted.

Is there any scenario under which a long commit message is detrimental, even if "messy"?

It's an issue when dealing with management or clients. They can see long commits as a problem with someone with too much time on their hands. The whole point of a version control system is that it contains everything related to the code. On lots of web dev and game projects you also commit the finalized assets (the generated javascript from coffeescript, the compressed 3d textures, etc. etc.)

That's not bad commit messages, that's bad client management.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#82

Post by nine_k »

sbov wrote: post #12
hinkley wrote: post #5

Earlier quoted context omitted.

I get really crabby about bad commit messages because on some projects, the commit history is the only 'Why' you ever get. Scratch that, on MOST projects that's the case.

I'm a fan of whys. Even for yourself. I have code I have to maintain that I wrote 10 years ago. But it can make for long commit messages. Why also includes what alternatives you considered, and why you didn't use those. I also like to have a digital "worksheet" for each change I do, where all my thoughts and research goes. So if all else fails, I can reference that. But no-one else can, so I like to transfer as much…

In my case, only key whats and whys go to the commit message. Most of the discussion is left in the issue tracker.

(Of course, the commit message refers to issue ID, and vice versa.)

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#83

Post by Terr_ »

JohnBooty wrote: post #67
wellpast wrote: post #22

Earlier quoted context omitted.

I'll take a sound codebase and zero commit messages over a poorly structured codebase any day.

This choice makes no sense but.... hmm, really? I think I'd rather have good commit messages that explain the "whys" that went into the code. Code typically isn't rocket science. It's the human knowledge that goes into it that's irreplacable. Example 1: OK, you're using a third-party CSV parser instead of the one built into the standard library. Why? If your code is crap but well-documented, I can read what you were…

In both of your examples, I believe comments in the code are the real winning strategy, rather than the individual commit-messages.

99% of the time what you want is to understand the current code--or at least code at a specific past point in time--as opposed to every transition that occurred.

For the CSV parser, I'd rather see a comment ("/* We use this for >2gb support */") or a test case ( testOverTwoGigsParseable() ) would be a lot more useful than any level of discipline over commit-messages.

For Mary's commission-calculator, it sounds like nobody has access to good "whys" anyway, because they boil down to "salesguy X insisted on it". Instead, the commits are functioning as an auditing/blame tool.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#84

Post by hinkley »

rwallace wrote: post #77
pacaro wrote: post #15

Earlier quoted context omitted.

Guilty as charged. Or maybe 'nolo contendere'. I just dropped 5kloc, 6 weeks work, into a repo with the message "Initial commit" I'm currently working on the changes that will actually document what is otherwise a walk of code. The road to hell is paved with good intentions.

Eh, uninformative commit messages aren't a sin, they're a trade-off. Right now, most of my commit messages are one word. Why? Because at the moment nobody cares about my commit messages because nobody cares about my project because it doesn't yet do anything useful. Getting to the point where it does something useful has higher priority than writing long messages nobody will read. Once the commit messages have an aud…

It's a self fulfilling prophecy though. If you want to be important you have to act important.

Yes, nobody cares about your commit messages until there's a bug or a major refactor. By then, if the commit messages suck, it's too late to do anything about it.

"Programs are meant to be read by humans and only incidentally for computers to execute"

Is never more true than when you're trying to fix bugs or make improvements. A project you can't improve is a dead project.

Post reply on HN