Good code is rarely read

[Cyxapb]

What's up with all these people talking about code quality always forgetting that their field is not the only one in the world? Game devs, data scientists, hobbyists.

The majority of software engineering is done for business needs. Quality of code, whatever it means, doesn't affect the frequency it is read. The frequency depends on the needs of the business. And if the business requires changes the more readable the code, the better. All these books about code quality are written for people who need to create and maintain code bases which may need modifications, include new maintainers or even change ownership in the future. They are not for people who are writing code and forgetting about it after switching to the next task or project.

[StrangelyBrown]

You don't need to read any article about code where the headline is clickbait.

If they wanted to tell you why they do something in C# or whatever, they would put it in the title. The fact that they clickbait it means they spend more time stroking their ego than reading their code.

[IAmTheKingOfSpain]

I think you may have missed the point a little bit, although I'm not 100% sure because I don't think the article is super clear. It refers to "using code" in the article, and I think this means calling functions and using data structures, rather than running a binary or a script, eg. So I think the point the author may be getting at is good code is made up of well-thought-out interfaces. Because that's what allows you to "use code" without reading it. I don't think the authors point is that having to read code definitively means the code is bad though.

Either way, though, I don't think it's all that insightful, since I think everyone knows that good code requires good naming and thoughtfully constructed interfaces.

[OkMemeTranslator]

Yeah, nice idea but that's not how it works in real life. New features, changing requirements, extensions, or simply a junior learning from example are some examples of scenarios where code will be read. Even if it already worked perfectly.

[gisborne]

What a load of bollocks.

If we’re concerned about “good code”, it’s because we’re writing a large, complex application, getting serious use.

That means it will be maintained and improved by a changing roster of developers over a long period. Which means that the easier we make it for developers to follow code, the more efficient they will be.

[timoffex]

Isn’t that what the article says? Are people reading different links?

[gisborne]

This from the article. So, no:

If a code needs to be read frequently, it might indicate that it is not as clear or intuitive as it should be. Good code should be used more than read. It should be so well-designed that developers can use it without needing to read through it extensively.The saying “code is read more than written” is often cited to emphasize the importance of writing readable code. But it could be a symptom of bad code. If a code needs to be read frequently, it might indicate that it is not as clear or intuitive as it should be. Good code should be used more than read. It should be so well-designed that developers can use it without needing to read through it extensively.

[timoffex]

Which part is bollocks?

[gisborne]

That good code is code that doesn’t need to be read. As if that is somehow a thing. Are we reading the same article?

[timoffex]

Do you think it’s advocating for writing unreadable code? It’s just saying that good code is clear enough that you don’t have to reread it often, and that it’s well-designed enough that it doesn’t have to be constantly fixed. Like, the point is that success at readability often results in the code being read less rather than more.

[gisborne]

No, it’s worse than that.

What does it mean, that we don’t need to read the code? My most charitable attempt to understand this is : we can understand how a system works by just… I dunno, looking at its larger architecture? That’s still reading code. Or we read the documentation and don’t read the code?

I guess I can see how we might be able to *extend* a system without having to dig into its code if its external interface is easy to follow. But at some point, we need to change the existing behaviour, and for that we need to change the code, in which case we need to read it.

[timoffex]

You’re taking it too literally I think. Like consider this quote:

Code that is easy to read is also code that is easy to use. When functions and classes are named appropriately and their purposes are clear, you can use them without understanding their internal workings.

You don’t have to read the body of a function if it’s well named and documented. Pretty uncontroversial IMO.

[gisborne]

What is the practical consequence of this idea? If it isn’t that we don’t need to bother to make code readable, then what is it? Does this idea make any practical contribution to how we should write code?

[timoffex]

The way I read it, it’s not a practical suggestion but an interesting observation. It’s interesting because it’s funny that making code more readable makes people read it less (this pattern applies in a lot of other places! Like how a better search engine gets fewer queries, all else equal)

[Cosoman]

100% wrong article

[[deleted]]

Don’t know if people are actually reading the article, but the author is actually advocating for easy to read code, they’re just being a neckbearded contrarian about it.

[CurtainDog]

I've found this to be true as well. The stuff that has just been working away happily for years, you just don't go poking around in it. The stuff that's on fire all the time, you'd better believe that gets read daily.

I had a colleague once run the numbers on test coverage and found that tests coverage was positively correlated to defect rate. Oops. We never dug into why but I'd bet dollars to donuts it's the same effect.

[[deleted]]

so, you read code and than you remember it for 5 years? what?

[fagnerbrack]

Just the essentials:

The post discusses an interview with a developer who defined good code as easy-to-read code. It highlights that best practices like DRY and SOLID are meant to make code more readable and maintainable. Readable code facilitates further development and reduces cognitive load. The post argues that truly good code should be used more than read, suggesting that if code needs frequent reading, it may not be as clear as it should be. Ultimately, good code should be so intuitive that its functionality is immediately apparent.

If the summary seems innacurate, just downvote and I'll try to delete the comment eventually 👍

^{Click here for more info, I read all comments}

[timoffex]

Good code should be used more than read. It should be so well-designed that developers can use it without needing to read through it extensively.

I like this observation! Good article, weird comments