4 ms·

Code quality can also be codified. If you can't express "code quality" deterministically, then it's all just feels. And if you can define "quality" in a way th

Code quality can also be codified. If you can't express "code quality" deterministically, then it's all just feels. And if you can define "quality" in a way the agent can check against it, it will follow the instructions.

embedding-shape 7mo ago
> then it's all just feels Would that be so bad? "Readability" sure is subjective, so it seems "code quality" is. Ask 10 programmers what quality a snippet of code is, and you'll get 10 different answers.
- theshrike79 7mo ago
  And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it. But when you pick a style and enforce it with a tool like gofmt or black both locally and in the CI, the arguments go away. That's the style all code merged to the codebase must look like and you will deal with it like a professional. Go proverb: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
  - embedding-shape 7mo ago
    "Style" is such a small part about what people generally care about when they talk about code quality though, useful/intuitive abstractions, the general design and more tends to be a lot more important and core to the whole code quality debate.
    - theshrike79 7mo ago
      Linters can be set check for cyclomatic complexity, using old/inefficient styles of programming (go fix ftw) etc. Formatting is just an easy and clear example that everyone should understand.
      - embedding-shape 7mo ago
        Right, but all of those are easy, left is the actually hard stuff...
  - deadbabe 7mo ago
    Amateurs are the one who argue about syntax. Code quality is about how well a piece of code expresses what it intends to do. It’s like quality writing.
    - ChrisMarshallNY 7mo ago
      Syntax and style can be very important, when transferring code. I’m generally of the opinion that LLM-supplied code is “prolix,” but works well. I don’t intend to be personally maintaining the code, and plan to have an LLM do that, so I ask the LLM to document the code, with the constraint being, that an LLM will be reading the code. It tends to write somewhat wordy documentation, but quite human-understandable. In fact, it does such a good job, that I plan on having an LLM rewrite a lot of my docs (and I have a lot of code documentation. My cloc says that it’s about 50/50, between code and documentation). Personally, I wish Apple would turn an LLM loose on the header docs for their SwiftUI codebase. It would drastically improve their docs (which are clearly DocC). [EDITED TO ADD] By the way, it warms my heart to see actual discussion threads on code Quality, on HN.
    - theshrike79 7mo ago
      You start to care about standard syntactic rules and enforced naming conventions when you're the one waking up 4 in the morning on a Saturday to an urgent production issue and you need to fix someone else's code that's written in a completely incoherent style. It "expresses what it intends to do" prefectly well - for the original author. Nobody else can decipher it without spending significant amounts of memory cycles. Jack Kerouac is "quality writing" as is the Finnish national epic Kalevala. But neither are the kind you want to read in a hurry when you need to understand something. I want the code at work to be boring, standard and easy to understand. I can get excited by fancy expressive tricks on my own time.
      - deadbabe 7mo ago
        What do you mean exactly? Are you the type that hates seeing comprehensions and high order functions and would rather just see long for loops and nested ifs?
  - datsci_est_2015 7mo ago
    > And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. Holy strawman Batman! Have you ever given a code review? These are the lowest items on the totem pole of things usually considered critical for a code review. Here’s an example code review from this week from me to a colleague, paraphrased: “We should consider using fewer log statements and raising more exceptions in functions like this. This condition shouldn’t happen very often, and a failure of this service is more desirable than it silently chugging along but filling STDOUT with error messages.”
    - theshrike79 7mo ago
      So you're fine with people using, for example, different brace styles at random? Or one person uses var everywhere, other uses definite types. One adds standard docstrings on every function and property, one never comments a single line of code. Don't you have "format on save" enabled in your editor? When you open a file, change two lines and save -> boom 500 changed lines because the previous programmer had different formatting rules than you. Whoops. This is why the low totem pole stuff needs to be enforced automatically so that actual humans can focus on the higher stuff that's about feels and intuition - things that are highly context dependent and can't be codified into rules.
      - datsci_est_2015 7mo ago
        > Code quality can also be codified. If you can't express "code quality" deterministically, then it's all just feels. And if you can define "quality" in a way the agent can check against it, it will follow the instructions. … > This is why the low totem pole stuff needs to be enforced automatically so that actual humans can focus on the higher stuff that's about feels and intuition - things that are highly context dependent and can't be codified into rules. I’m confused, have you switched your position on this topic over the course of this thread? Maybe I’ve misinterpreted your position entirely. If so, my bad.
      - dotancohen 7mo ago
        You're bikeshedding in a conversation about real issues. After a certain point in your career you don't care what brace style the new dev used, even if the project has lint rules. You do care if critical errors are ignored and possibly incorrect data is returned. These two situations are in no way equivalent, no need to bikeshed the former when discussing the latter.
  - mchaver 7mo ago
    > And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. In my 15 years of experience I have not worked at a place like this. Those are distractions. Anytime something about style has been brought up, the solution was to just enforce a linter/pre-commit process/blacklist for certain functions, etc. It can easily be automated. When those tools don't exist for particular ecosystems we made our own.
- benswerd 7mo ago
  I disagree with this. My team will send me random snippets from OSS libraries and we all go WTF what is that, and my team will also send really clever lines and we'll go wow. "Good code" is subjective, but good engineers have good taste, and taste is real.
datsci_est_2015 7mo ago
> Code quality can also be codified. Do you think that no one has tried this over the past 80 years with human programmers, but now with LLMs we can suddenly manage to do it? Why do linters and formal verification and testing exist if we could’ve jus codified coding quality in the first place? To me, this is like telling a carpenter that we can codify what makes a chair comfortable or not.

embedding-shape 7mo ago

> then it's all just feels Would that be so bad? "Readability" sure is subjective, so it seems "code quality" is. Ask 10 programmers what quality a snippet of code is, and you'll get 10 different answers.

theshrike79 7mo ago
And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it. But when you pick a style and enforce it with a tool like gofmt or black both locally and in the CI, the arguments go away. That's the style all code merged to the codebase must look like and you will deal with it like a professional. Go proverb: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
- embedding-shape 7mo ago
  "Style" is such a small part about what people generally care about when they talk about code quality though, useful/intuitive abstractions, the general design and more tends to be a lot more important and core to the whole code quality debate.
  - theshrike79 7mo ago
    Linters can be set check for cyclomatic complexity, using old/inefficient styles of programming (go fix ftw) etc. Formatting is just an easy and clear example that everyone should understand.
    - embedding-shape 7mo ago
      Right, but all of those are easy, left is the actually hard stuff...
- deadbabe 7mo ago
  Amateurs are the one who argue about syntax. Code quality is about how well a piece of code expresses what it intends to do. It’s like quality writing.
  - ChrisMarshallNY 7mo ago
    Syntax and style can be very important, when transferring code. I’m generally of the opinion that LLM-supplied code is “prolix,” but works well. I don’t intend to be personally maintaining the code, and plan to have an LLM do that, so I ask the LLM to document the code, with the constraint being, that an LLM will be reading the code. It tends to write somewhat wordy documentation, but quite human-understandable. In fact, it does such a good job, that I plan on having an LLM rewrite a lot of my docs (and I have a lot of code documentation. My cloc says that it’s about 50/50, between code and documentation). Personally, I wish Apple would turn an LLM loose on the header docs for their SwiftUI codebase. It would drastically improve their docs (which are clearly DocC). [EDITED TO ADD] By the way, it warms my heart to see actual discussion threads on code Quality, on HN.
  - theshrike79 7mo ago
    You start to care about standard syntactic rules and enforced naming conventions when you're the one waking up 4 in the morning on a Saturday to an urgent production issue and you need to fix someone else's code that's written in a completely incoherent style. It "expresses what it intends to do" prefectly well - for the original author. Nobody else can decipher it without spending significant amounts of memory cycles. Jack Kerouac is "quality writing" as is the Finnish national epic Kalevala. But neither are the kind you want to read in a hurry when you need to understand something. I want the code at work to be boring, standard and easy to understand. I can get excited by fancy expressive tricks on my own time.
    - deadbabe 7mo ago
      What do you mean exactly? Are you the type that hates seeing comprehensions and high order functions and would rather just see long for loops and nested ifs?
- datsci_est_2015 7mo ago
  > And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. Holy strawman Batman! Have you ever given a code review? These are the lowest items on the totem pole of things usually considered critical for a code review. Here’s an example code review from this week from me to a colleague, paraphrased: “We should consider using fewer log statements and raising more exceptions in functions like this. This condition shouldn’t happen very often, and a failure of this service is more desirable than it silently chugging along but filling STDOUT with error messages.”
  - theshrike79 7mo ago
    So you're fine with people using, for example, different brace styles at random? Or one person uses var everywhere, other uses definite types. One adds standard docstrings on every function and property, one never comments a single line of code. Don't you have "format on save" enabled in your editor? When you open a file, change two lines and save -> boom 500 changed lines because the previous programmer had different formatting rules than you. Whoops. This is why the low totem pole stuff needs to be enforced automatically so that actual humans can focus on the higher stuff that's about feels and intuition - things that are highly context dependent and can't be codified into rules.
    - datsci_est_2015 7mo ago
      > Code quality can also be codified. If you can't express "code quality" deterministically, then it's all just feels. And if you can define "quality" in a way the agent can check against it, it will follow the instructions. … > This is why the low totem pole stuff needs to be enforced automatically so that actual humans can focus on the higher stuff that's about feels and intuition - things that are highly context dependent and can't be codified into rules. I’m confused, have you switched your position on this topic over the course of this thread? Maybe I’ve misinterpreted your position entirely. If so, my bad.
    - dotancohen 7mo ago
      You're bikeshedding in a conversation about real issues. After a certain point in your career you don't care what brace style the new dev used, even if the project has lint rules. You do care if critical errors are ignored and possibly incorrect data is returned. These two situations are in no way equivalent, no need to bikeshed the former when discussing the latter.
- mchaver 7mo ago
  > And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. In my 15 years of experience I have not worked at a place like this. Those are distractions. Anytime something about style has been brought up, the solution was to just enforce a linter/pre-commit process/blacklist for certain functions, etc. It can easily be automated. When those tools don't exist for particular ecosystems we made our own.
benswerd 7mo ago
I disagree with this. My team will send me random snippets from OSS libraries and we all go WTF what is that, and my team will also send really clever lines and we'll go wow. "Good code" is subjective, but good engineers have good taste, and taste is real.

datsci_est_2015 7mo ago

> Code quality can also be codified. Do you think that no one has tried this over the past 80 years with human programmers, but now with LLMs we can suddenly manage to do it? Why do linters and formal verification and testing exist if we could’ve jus codified coding quality in the first place? To me, this is like telling a carpenter that we can codify what makes a chair comfortable or not.