everything only matters in context. In general.
Code quality only matters in context (2019)
31–40 of 78 posts
Re: Code quality only matters in context (2019)
#32The author confused cause and effect. Author: because this code sees a lot of churn it is important. Reality: this code sees a lot of churn because it is bad.
Even if that's the case the author's point still stands, focusing the code quality in this code makes more sense, if it's bad.
Re: Code quality only matters in context (2019)
#33The author confused cause and effect. Author: because this code sees a lot of churn it is important. Reality: this code sees a lot of churn because it is bad.
> this code sees a lot of churn because it is bad
That’s one possibility. It’s also possible that it changes a lot because it’s related to business rules, which are typically more volatile than infrastructure code.
Re: Code quality only matters in context (2019)
#34This mindset is also true for many researchers who code. Professional programmers make fun of research code but actually the dirty way is desirable considering that research is about prototyping, tweaking, and in small groups.
To that I say: there's dirty code -- then there's researchers' code. It can be a whole new level, far beyond just copy-paste and other superficial sins.
Re: Code quality only matters in context (2019)
#35I think the conclusion here is back-to-front. Code that never needs to be touched is fine. Although the odds are that such code is either completely trivial or subtly wrong (or both). Code that is touched every day is likely to be fine as well. It's should get smoothed out naturally, like a pebble in a stream. If not, you probably already have lots of alarm bells telling you it's a problem without the need for any fu…
> A better metric for deciding where you should focus the most effort on code quality is not frequency of modification, it is frequency of appearance in the runtime call-graph.
On th flip side, a lot of code that isn't common in the main codepath often exists to fix edge case bugs that people have lost context on. In my experience, this code is a landmine with an unknown blast radius, only touch it with a 10-foot pole and only when you absolutely must.
Re: Code quality only matters in context (2019)
#36While I'm extremely sympathetic to this idea, one question nags at me: Long-tail code can also be long tail because _it was well-written from the beginning_. The author is arguing that long tail code lives in a stable, unchanging corner of the business. This can absolutely be true, but it can also be true that a well-written abstraction may service new needs without needing to be changed. (In practice, this is hard.)
This.
Re: Code quality only matters in context (2019)
#37"We developers mostly read code, so let's optimise the writing part by writing bad code that will be slower to read."
Am I the only seeing a problem here?
Re: Code quality only matters in context (2019)
#38This mindset is also true for many researchers who code. Professional programmers make fun of research code but actually the dirty way is desirable considering that research is about prototyping, tweaking, and in small groups.
To that I say: there's dirty code -- then there's researchers' code. It can be a whole new level, far beyond just copy-paste and other superficial sins.
Research code has different priorities.
I have a set of repos I pull down for vivisecting software projects.
They would be horrific to anyone else. I do horrible things to other peoples' code. Idioms clash, the style and messaging and comments can seem schizophrenic, and you'll run into things that'll send professionaal coders running like custom instrumented versions of the language runtime. Everything that can be done wrong in them, generally is, and it's tuned for one thing.
Figuring out how to read it, why it works, and where to poke it to change it. I'm one of those people who'll sit down with an entire rcosystem of code and go Dr. Moreau on it.
...Then I turn around and push the well documented, polished, minimum viable changeset into the professional repo, and lock away the horrible atrocities I have wrought far from the eyes of Man, hopefully well enough that only God will eventually pass judgement.
Re: Code quality only matters in context (2019)
#39> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…
> And that's how the long tail becomes long tail.
Not really.
Developers should only touch production code if there is a good business reason to touch it, whether fixing a bug or adding a feature. If there is no good reason to touch a bit of code, you should not be touching it. Otherwise you're just adding noise to the audit trail, perhaps along with bugs in otherwise perfectly fine code, without any justification.
The long tail is a long tail because there are no bugs not reasons to mess around in those parts of the code. Feeling adventurous is not a good reason to mess with it. If you have to implement a feature or fix a bug, complaining that it's old code won't make things go away.
Re: Code quality only matters in context (2019)
#40Earlier quoted context omitted.
>Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it. Writing clean code and leaving the place better than you found it requires time. Time we generally just do not have. There comes a point where things just have to work , and all of your ideas about what is "right" and "clean" have to be set aside to make that happen.
This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.
> This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.
This is not true at all. The definition of "clean code" is highly subjective and context- and experience-dependent. Your personal opinion and feelings towards a code style are not the same as bugs, nor is a lack of compliancd with your personal taste a potential liability similar to not adding a test.