Linus Torvalds: 'I Do No Coding Any More'

Post by alphachloride » Mon, Jul 06, 2020, 4:37 AM UTC

phkahler wrote: post #185

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…

>> Yep, no one ever reads them and the cost to benefit ratio is extremely low. You're projecting. YOU never read them. I used to be the same way. Now I see other people reading them and I've started to myself. I follow other people's efforts and progress. It's a great way to learn not only the code but to communicate better.

Post by burfog » Mon, Jul 06, 2020, 5:35 AM UTC

zabzonk wrote: post #61

nullc wrote: post #49

Earlier quoted context omitted.

> about how a code base "is crap" Translation: "Not written in the particular arbitrary style that I'm used to", of course if it were written in that persons preferred style another arbitrarily selected novice would call the result crap. I've found this to be almost universally true especially when the claim is given forcefully but not immediately backed up with a litany of actual user-impacting serious problems. Thi…

> Not written in the particular arbitrary style that I'm used to Like "arbitrary styles" such as "a function shall not be 500 lines long".

Post by tdeck » Mon, Jul 06, 2020, 5:40 AM UTC

vp8989 wrote: post #155

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…

All the "code quality" people write shitty systems. You are too zoomed in if you think code quality is really important. It's kind of important, but your system likely has much more important things wrong with it than the "code quality". Things you could actually get fired for, or seriously reprimanded if the winds don't blow in your favor. Almost all "code quality" discussion in PRs is lightweight value judgements w…

Post by staycoolboy » Mon, Jul 06, 2020, 6:15 AM UTC

mkl wrote: post #181

staycoolboy wrote: post #121

Please next time link to the source and not to another discussion forum: https://www.youtube.com/watch?v=H8Gd9t7FQqI

Many of us don't have time (or inclination) to watch a 25 minute video just for a few key sentences. Yes, I'm sure there are other interesting things in the video too, but that bit is what the submitter found interesting enough to submit, and what the upvoters found interesting enough to upvote, and the link to the source is on the first line.

Post by jkaplowitz » Mon, Jul 06, 2020, 6:46 AM UTC

cwsx wrote: post #201

jkaplowitz wrote: post #167

Earlier quoted context omitted.

I've never seen that anywhere I've worked, though it's a readable enough format that it wouldn't bother me if someone decided to adopt it for a good reason like compatibility with parsing by dev workflow dashboards or other automatic tooling. Though, I'm not sure it's a helpful restriction for commits that clarify, refactor, or clean up code. One can certainly reference an issue tracker number as the {feature/bug} el…

I should note this is normally done on a feature branch (with the ticket number attached). i.e. feature/{ticket-#}-{ticket-title} When merging you can pretty easily see what ticket each commit was for. Seems superfluous to put the same information in every commit messages.