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

241–246 of 246 posts

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

#241

Post by rcxdude »

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.

It's rigorously studied but it's a crap thing to put an arbitrary restriction on, because it doesn't correlate well enough to warrent that. If you put a restriction on it, bad code still gets through fine while some good code gets made worse to bypass the checks (the biggest one is large switch statements acting as dispatch: Perfectly understandable, but if you split such a thing into multiple functions magically the cyclomatic complexity goes down to satisfy the linter but the code has just gotten harder to understand for static analysis and humans alike).

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

#242

Post by g-b-r »

ozim wrote: post #79
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…

I really love those useless comments in the code that state in plain english what code does but nothing more. Such a waste of space. Bonus points if offenders are using bad variable names like "var asd = fuFunc();" and instead of naming those in clear way they add comments. Like you could save memory space on variable/function names or something and those guys were not form the 80's.

In my experience the people who write "var asd = fuFunc();" also write awfully short uninformative commit messages

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

#243

Post by [deleted] »

technics256 wrote: post #32
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…

Where can one learn the art of excellent commit messages and when to rebase, etc?

[deleted]

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

#244

Post by g-b-r »

technics256 wrote: post #32
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…

Where can one learn the art of excellent commit messages and when to rebase, etc?

There's no "excellent", it's all opinions.

Just look at the "imperative" that almost everyone recommends, try for enough times to cherry-pick commits that claim to do something and you'll realize how misleading they are

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

#245

Post by greyhair »

systemvoltage wrote: post #103
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…

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…

Comments and commit messages both matter. For different reasons.

Comments are often wrong, for the wrong reasons. People that change code, but don't update the comments to reflect the code change are evil. But then, people that put to much superfluous information in comments, that should just be left to the code, are also evil.

BTW, if your code implements a part of a standard, try putting the standard, and what subsection, your code addresses. Just the reference not the text. 802.11G for example (old fart) or TA55, or RFC 1536. Whatever. Then list the date of the document and the subsection.

I had to modify a Reed-Solomon implementation many years ago, and the original two authors based the implementation on a particular textbook. They gave the ISBN and then chapter/paragraph/table/illustration references on each block. I went and got a copy of the book, and it all lined up perfectly. Best documented code I have ever encountered.

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

#246

Post by greyhair »

u801e wrote: post #200
usrusr wrote: post #187

Earlier quoted context omitted.

Comments aren't supposed to state the obvious and at the time it probably was. Commit messages are redundant by definition (everything said in the message is supposedly already there in the diff) so they are like magnets for stating the seemingly obvious.

> Commit messages are redundant by definition (everything said in the message is supposedly already there in the diff) Commit messages are far easier to parse and understand compared to a moderate size diff. By reading the commit message before looking at the diff, it really helps in terms of understanding the context of the diff and what to expect.

More than that, I find moderately sized 'git' diffs in PRs to be unreadable. I frequently have to open the full code block to see what is taking place in the source.

Commit messages provide intent, and should reference the original change request to see what the commit was intended to fix.

I would say the whole chain matters.

A good change request (Jira) with defects, and how to recreate the fault, as well as relevant requirements (by reference, not cut-n-paste)

Good comments on the code that is changing. Don't document the defect and how you fixed it, just comment what the code does (if the code is not perfectly clear),

Then a good commit message, referencing the change request, to tie it all together.

It all matters.

Post reply on HN