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

Linus Torvalds: 'I Do No Coding Any More'

linux.slashdot.org

Post reply on HN
Print view View original

111–120 of 246 posts

Re: Linus Torvalds: 'I Do No Coding Any More'

#111

Post by systemvoltage »

0xEFF wrote: post #109
systemvoltage wrote: post #103

Earlier quoted context omitted.

Yep, no one ever reads them and the cost to benefit ratio is extremely low. Writing good comments is far more important. Don't explain what the code does - that's what the code is for, explain the why and the background information in the code. Additional, explain what the code does at the function level or at the module level - at a much higher abstraction level basically than the line of the code. No one ever looks…

I look at commit messages quite often working on a 10+ year old code base. Bisect leads to the commit, the commit message explains why the change was made. I take the explanation from 10+ years ago and determine if the reason still applies today. Or, I bisect and there's a low quality commit from 10 years ago from a person long since departed that simply says "fixup" and I'm dead in the water.

Commit messages are supposed to be short. "Fixed stuff" is totally wrong. I usually write "Added ability to do foo with bar when baz is true."

Commit messages aren't mutually exclusive to the inline documentation.

I am making the case that inline documentation is far more important than commit messages.

Re: Linus Torvalds: 'I Do No Coding Any More'

#112

Post by ulrikrasmussen »

pengaru wrote: post #34
hasmolo wrote: post #6

Earlier quoted context omitted.

I've seen that useful commit message make it incredibly easy to see where the code came from and is going. It also never gets 'out of sync' like code comments tend to, as it's a comment on a static place in the code, not a dynamic one.

> It also never gets 'out of sync' like code comments tend to, as it's a comment on a static place in the code, not a dynamic one. That's simply not true, not in a git world where rebasing to rewrite history is standard practice.

In that case rebasing rather than merging would be the wrong choice, since you're actively obfuscating the history.

Re: Linus Torvalds: 'I Do No Coding Any More'

#113

Post by swsieber »

mrisoli wrote: post #92
dasil003 wrote: post #26

> commit messages to me are almost as important as the code change itself This is high on my list of code craftsmanship points. It's very difficult to explain to young programmers who have never worked on an old code base how valuable this is when done well. In fact, often you hear complaints about how a code base "is crap", but more often than not I'd wager this is just a result of the context at the time not being…

I write detailed commit messages for every single commit I make(even though commits would be squashed on merges), I write detailed PR descriptions that included before/after screenshots in multiple resolutions whenever relevant. Never once did I have any indication that someone took their time to read descriptions or commit messages. In my previous job, I received some feedback from my manager that some people compla…

I highly doubt _you_'ll be the one to pay dividends for detailed commit messages.

Re: Linus Torvalds: 'I Do No Coding Any More'

#114

Post by Lammy »

xfitm3 wrote: post #15
hirundo wrote: post #7

This is sad, not so much because of the lack of code coming from this world class programmer, but because coding is such fun, and Torvalds isn't having fun programming, else he'd be doing it. I'm closing in on forty years of coding and still get a kick out of it. I'd still be doing it if I weren't getting paid for it. But my skills are at best, uh, modest compared to Linus. I'd think that doing a thing so much better…

Coding is fun but for me collaborative development has stopped being fun. People can be rude, biased, and it seems there is always someone with 50 questions or a concern who sucks the life right out of it.

I wish Github let me disable Pull Requests on my repos for this reason. You can disable Issues, Wikis, and lots of other features, but not Pull Requests. For certain projects I end up checking a `.github/lockdown.yml` into my repo and using https://github.com/dessant/repo-lockdown

Re: Linus Torvalds: 'I Do No Coding Any More'

#115

Post by oefrha »

0xEFF wrote: post #109
systemvoltage wrote: post #103

Earlier quoted context omitted.

Yep, no one ever reads them and the cost to benefit ratio is extremely low. Writing good comments is far more important. Don't explain what the code does - that's what the code is for, explain the why and the background information in the code. Additional, explain what the code does at the function level or at the module level - at a much higher abstraction level basically than the line of the code. No one ever looks…

I look at commit messages quite often working on a 10+ year old code base. Bisect leads to the commit, the commit message explains why the change was made. I take the explanation from 10+ years ago and determine if the reason still applies today. Or, I bisect and there's a low quality commit from 10 years ago from a person long since departed that simply says "fixup" and I'm dead in the water.

Yup, way too many times I’ve encountered code that’s written in a peculiar way obviously for a reason, most likely to work around some issue, but it’s not clear what the issue is and whether it is otherwise resolved so that the peculiar code can be dropped. I bisect and it says “fix bug”, now I need to carry that crap forever or worry about reintroducing some unknown bug.

(In case someone points out a comment is more suitable: comments are less likely to survive refactors, and people who write terrible commit messages also tend to be terrible commenters. Informative commit messages supplement good comments.)

Re: Linus Torvalds: 'I Do No Coding Any More'

#116

Post by aeontech »

dtech wrote: post #107
mrisoli wrote: post #92

Earlier quoted context omitted.

I write detailed commit messages for every single commit I make(even though commits would be squashed on merges), I write detailed PR descriptions that included before/after screenshots in multiple resolutions whenever relevant. Never once did I have any indication that someone took their time to read descriptions or commit messages. In my previous job, I received some feedback from my manager that some people compla…

Spending time on commit messages that will be essentially removed when the PR is squashed seems... not very productive

And that’s why PR squashing is counter-productive. Good luck trying to track down an issue when bisect leads you to a 1500 line commit containing an entire feature.

Repo commit history is an artifact the team produces, as much as the code it contains.

Re: Linus Torvalds: 'I Do No Coding Any More'

#117

Post by pcl »

jacquesm wrote: post #87
LeonidBugaev wrote: post #74

Earlier quoted context omitted.

Head of Engineering with 15 years of experience here. If found that when we starting using Github flow, with pull-requests and etc, commit messages stopped really matter, in favour of PR descriptions. Plus when you use "squash" strategy, and use PR description as commit message, history looks great. When you look at commit history through Github tooling, all PR ids turned into links, and it is very easy watch for the…

What's wrong with placing that documentation right where it belongs?: In the code.

I consider the version control history to be part of the code.

I put docs into the source tree (sometimes in the form of comments; sometimes in dedicated doc files) for things that are suited to live next to the code, but often my commit messages contain more discussion of what used to be and why I chose a certain implementation approach.

I generally think that documentation in code should describe what the code does and why, and commit messages should describe why critical choices were made and how the new approach differs from previous behavior.

This assumes a good version control system that follows history across renames and moves etc., of course.

Re: Linus Torvalds: 'I Do No Coding Any More'

#118

Post by grogenaut »

bob1029 wrote: post #29
xfitm3 wrote: post #15

Earlier quoted context omitted.

Coding is fun but for me collaborative development has stopped being fun. People can be rude, biased, and it seems there is always someone with 50 questions or a concern who sucks the life right out of it.

This is the key. I used to be really crabby with our codebase at work, and programming in general, because it was the only thing I developed on. I have recently adopted a large, sprawling side-project of which I am the sole developer. Having a big space to play in on the side has really helped me keep my interest pure and exciting. Not answering to anyone but myself is easily the best aspect. The codebase is private…

I'm sure your coworkers thank you for not using the work code base as your personal playground. I always prototype things in side projects or actual work prototypes that I delete or recode from scratch.

People get so hung up on how cool the thing they just did is and not at all on was useful. Sometimes you just gotta let it rest for a month to get over that honeymoon phase.

Re: Linus Torvalds: 'I Do No Coding Any More'

#119

Post by nemetroid »

tmh88j wrote: post #110
nemetroid wrote: post #101

Earlier quoted context omitted.

Requirements change over time, and so do the "why"s. So unless the code base is your primary documentation for requirements, "why" comments in the code can be dangerous: while outdated "what" comments can be determined as such by reading the code, there is no way (from the code itself) to determine whether a "why" comment is still accurate. A "why" comment in a commit message, on the other hand, only tells you what t…

>So unless the code base is your primary documentation for requirements, "why" comments in the code can be dangerous No, but you seem to be implying that commit messages serve that purpose. If your code changes why wouldn't you add new comments and remove outdated/misleading comments? >A "why" comment in a commit message, on the other hand, only tells you what the "why" was at that time, something that cannot become…

> If your code changes why would you leave outdated and misleading comments?

The point is that the code might not change. When you wrote it, maybe it was to cover use cases A and B. Sometime later, a new use case ”C” is added to the requirements, and this particular part of the code happens to already support C without making any changes.

Now, further down the line, some developer comes along to work on this code. If there’s a comment saying ”this code was written to support use cases A and B”, the developer will likely not take C into consideration when making their changes, and risk subtly breaking things.

Re: Linus Torvalds: 'I Do No Coding Any More'

#120

Post by oefrha »

dtech wrote: post #107
mrisoli wrote: post #92

Earlier quoted context omitted.

I write detailed commit messages for every single commit I make(even though commits would be squashed on merges), I write detailed PR descriptions that included before/after screenshots in multiple resolutions whenever relevant. Never once did I have any indication that someone took their time to read descriptions or commit messages. In my previous job, I received some feedback from my manager that some people compla…

Spending time on commit messages that will be essentially removed when the PR is squashed seems... not very productive

By default a squash would collect all commit messages.

Also, I agree with aeontech that artificially mandating PRs to be squashed is very counter productive and often hinders bisect. Large features should be implemented in atomic units as a series of commits.

Post reply on HN