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

81–90 of 246 posts

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

#81

Post by rootusrootus »

tmh88j wrote: post #71
justapassenger wrote: post #54

Earlier quoted context omitted.

This so, so much. Too many people think that commit message is to explain HOW you did something. Unless you did something extremely clever (and in any commercial project, 99% of clever solutions are wrong - simple is the king), it should need more than few words. WHY you did it this way is the most important part. Given known and understood set of constrains, a lot of engineers will come up with similar solution, or…

>Too many people think that commit message is to explain HOW you did something. >WHY you did it this way is the most important part. What was done is better suited for the commit message than how and why it was done, in my opinion. The latter two are better explained by comments in the code. I agree that why something was done is important for future reference, but when I'm tracking down code changes I'm looking for…

> The latter two are better explained by comments in the code

Totally agree. Commit metadata is nice to have, but ultimately I think good code mostly explains "how" by the code itself, and "why" should be comments. Especially for local context, where the why has to do with some other bit of code. Individual commit messages are also secondary to the pull request merge commit, which should have a better explanation of the goal, or tie it to a task, etc.

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

#82

Post by secondcoming »

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…

Well, Linux's commit messages kind of have to be descriptive since Linux is an Open Source project that doesn't have (that I can see anyway) an issue tracker or other management tool.

When you do have those, then it's the ticket that gives the why's and how's. The commit messages do not have to be essays. And, at least with JIRA, if you name your branch such that it starts with the ticket id, it automatically picks up any pushed commits for that ticket. It's very useful.

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

#83

Post by nemetroid »

awinder wrote: post #78
Retric wrote: post #66

Earlier quoted context omitted.

An individual function can quite reasonably be 500 lines long. A giant case statement handling routing is one example. More controversially, if I am gong to need to do a lot of ugly compatibility hacks then I prefer to consolidate them and thus keep most functions clean.

Cyclomatic complexity is one of the more well-rigorously studied measure of code quality, I don’t know if I’d pick that hill to die on.

A function can be five hundred lines long without having high cyclomatic complexity.

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

#84

Post by gregmac »

LeonidBugaev wrote: post #74
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…

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…

The commit message with a good PR description is okay, but for any sizable code change still doesn't provide full context for an individual piece of code (git blame). Either the PR description is massive -- in which case it's hard to read and tell what applies where -- or it glosses over the detail that's necessary.

The thing is this isn't obvious why it's useful until you don't have it. I don't do it often, but the things that make me go back looking through git blame and history are trying to identify where hardcoded constants came from, or when (time or version) a particular bug was first introduced and why. This is only necessary when there aren't decent comments in the code already, and in my experience, the types of developers that don't put in these comments are also the ones that don't make highly detailed PR descriptions. Good commit messages is also a hurdle, but an easier one to get over than highly-detailed PR descriptions.

On top of that you get all the other significant downsides of a squash merge strategy (eg: not being able to tell the difference between a local branch being merged or not pushed; confusing merge conflicts if you ever merge branch->branch before merging one to master).

As an aside, IMHO, "clean history" is not at all a useful feature. Only developers are looking at git log to begin with, and they are quite capable of using `git log --merges` (or equivalent GUI operation). I guess the most useful thing is to make a CHANGES file (release notes) -- but honestly, the wording is different anyway (eg, "Fixed several minor UI issues" is adequate for release notes, but that might be across several PRs that contain more detail like "Fixed button alignment in modal dialogs", "Upgraded bootstrap to version x.y.z" etc). Go back and look at your PR descriptions from a year ago and see if you can make sense of them -- I bet the context of many will be lost.

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

#86

Post by geewee »

LeonidBugaev wrote: post #74
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…

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…

Azure devops also allows you to squash commits, I don't think this is Github specific. I do however agree with squashing commits in PRs being really nice (unless you want to branch out from a branch that gets squashed, then it sucks)

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

#87

Post by jacquesm »

LeonidBugaev wrote: post #74
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…

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.

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

#88

Post by iamstupidsimple »

neididipp wrote: post #42
tonyedgecombe wrote: post #31

Earlier quoted context omitted.

This is what I don't like about open source, it seems to encourage these sort of behaviours.

That’s interesting, because every office I’ve been in is like this while working only with and building proprietary software Tool flame wars, constant bike shedding, “that’s too abstract” premature optimization wars (apparently a list comprehension is too abstract for some eng, if-else all the way down!). Every Medium post by a tech somebody becomes a religious soapbox. I quit it all but kept my job. People complain…

> Edit: Oh almost forgot my “favorite”: environments where open source is leveraged heavily. Millions of lines of imported code, at best 5% was written internally. But somehow the business environment is that they’re engineering thought leaders for building a “tech biz” around a traditional business model. Smh

This is definitely a serious issue. Imo, unless the project is tiny, your own codebase should be at least the majority of whatever binary is shipped, otherwise you're adding very little value.

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

#89

Post by sushshshsh »

yxhuvud wrote: post #59
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…

Another thing those juniors are seldom good at, is knowing how to refactor an existing old code base. Which is not surprising, as everything they worked on during education is new code. Knowing how to change a code base from one abstraction to another is a skill that often take many years and lots of mistakes to learn.

Yet another boomer generalization designed to sow biases against hiring younger people.

At what age am I allowed to become a senior, oh wise one?

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

#90

Post by coliveira »

imtringued wrote: post #67
coliveira wrote: post #44

Earlier quoted context omitted.

What I notice personally is that many users of OSS these days are professional programmers using open source on their corporate jobs. They are trying to push their requirements and expectations on people that are not paid to deal with them.

The company can implement their own feature requests. I've opened some issues on some frameworks and when the maintainers agree with the issue the first thing they ask you is if you can submit a PR. Alternatively you can wait or sometimes pay for high priority handling. If you are unlucky you might wait forever because other people create issues too and those might be more important than yours.

This is possible, but more frequently what happens is that these professional developers will write bad reviews (in HN and elsewhere) about a project because they don't want or don't have time to support their wishes. This causes tremendous friction and makes it more difficult to maintain OSS these days.
Post reply on HN