7 ms·

So the rules can be codified sufficiently to test people on, but they can't be codified for a computer? The only one that sounds more difficult to codify is te

So the rules can be codified sufficiently to test people on, but they can't be codified for a computer? The only one that sounds more difficult to codify is telling people of the existence of duplicate functions. But as someone who contributes to the linux kernel, I can tell you right now that the only way that works reliably is to have a very large pool of reviewers. Very experienced engineers frequently miss what people are doing in other parts of the source base, the name might not be what they expect, etc, etc, etc. In the case of linux there are a fair number of duplicates, or similar functions, and people write coccinelle patches to replace them on a fairly regular basis after they have been in the kernel for years. So, I doubt giving someone a formal gatekeeper flag, really helps vs just having wider change review.

kccqzy 5y ago
> Very experienced engineers frequently miss what people are doing in other parts of the source base, the name might not be what they expect, etc, etc Very true. Readability can't help with that, nor is it designed to. It's mostly there to help novices and new hires. Experienced engineers already have readability themselves so they don't need this extra review.
compiler-guy 5y ago
I know of no automated tools available today that can determine if an identifier is accurately and usefully named. They can all tell if you are using the proper case, but that doesn't really tell you anything. No tool like that tells you if returning a bool instead of an enum is appropriate here, or that a reference vs a pointer makes more sense given the rest of the code. I'm sure a clever machine learning algorithm could figure that out with a corpus as large as Google's. Maybe. But no tool like that works today. And not strangely at all, Google does accept "what clang-tidy does" as the canonical way of formatting text. But readability at Google is far more than just formatting. Readability is frustrating and annoying, but more than just lint.
- dlubarov 5y ago
  > I know of no automated tools available today that can determine if an identifier is accurately and usefully named. Naming isn't very language-specific though [*], and poor naming should be flagged in coding interviews. Any Google engineer should generally have good naming, and should be able to critique others' naming in any language. [*] Granted there are some language-specific naming conventions, like ! and ? in Ruby methods. But I'd say the majority of languages don't have important naming conventions, and those that do often have lints for them.
  - vkou 5y ago
    > Naming isn't very language-specific though [*], and poor naming should be flagged in coding interviews. I'm not going to turn a candidate away because they use shorthand names when writing code under time pressure on a whiteboard.
    - Jensson 5y ago
      This discussion wasn't about hiring but about code reviews. If you use bad names in your code then the reviewer is correct when they tell you to make better names.
  - compiler-guy 5y ago
    "poor naming should be flagged in coding interviews" Exactly! And Readability process is exactly the training Google uses to ensure someone knows how to look for this issue, and that someone actually is looking for this issue in code reviews. There is plenty about the Readability process I don't like (particularly that one has to get it through a fairly artificial process), but checking for things like the above (which I just use as one easily understood example) isn't something that happens automatically in an organization as large as Google, with as many engineers as Google. A common story on HackerNews is just how bad the average programmer is, how crummy code they produce. Taking steps to ensure they do it better is a good thing. We can argue about the process, for sure, and there are many things I would love to change about it. But "yeah, that should be done in code reviews" is exactly the idea here.
gravypod 5y ago
> So the rules can be codified sufficiently to test people on, but they can't be codified for a computer? Small note: readability isn't a test or quiz you take (asterisk). It's obtained by merging code in the language you want readability for. If you merge code for a language often and the reviewers have very few style-based questions for the code then you will get readability fairly quickly. > The only one that sounds more difficult to codify is telling people of the existence of duplicate functions. But as someone who contributes to the linux kernel, I can tell you right now that the only way that works reliably is to have a very large pool of reviewers. Very experienced engineers frequently miss what people are doing in other parts of the source base, the name might not be what they expect, etc, etc, etc. A better example would be knowing when you should use `const std::string&`, `std::string_view` or `char*`. Example: https://abseil.io/tips/1 https://abseil.io/tips/1 The best readability advice I have recieved has been: 1. Direct "I was confused by X" or "The recommended way to do A is using B", etc 2. Reasoned: "std::string_view is more efficient and clearer in intention than char ptr, it also improves type safety as it is read only and clear about ownership" 3. Linked to source material where examples are given totw or other examples in the code.
anyfoo 5y ago
> So the rules can be codified sufficiently to test people on, but they can't be codified for a computer? I mean, given the halting problem alone, and the absence of general AI, yes, I'd say that... I'm not sure what to tell you otherwise. I've worked at a place with such strong coding style guidelines, and even though I personally did not agree with every individual point, I accepted the tradeoff because being able to count on consistency in a very large code base was extremely helpful.

kccqzy 5y ago

> Very experienced engineers frequently miss what people are doing in other parts of the source base, the name might not be what they expect, etc, etc Very true. Readability can't help with that, nor is it designed to. It's mostly there to help novices and new hires. Experienced engineers already have readability themselves so they don't need this extra review.

compiler-guy 5y ago

I know of no automated tools available today that can determine if an identifier is accurately and usefully named. They can all tell if you are using the proper case, but that doesn't really tell you anything. No tool like that tells you if returning a bool instead of an enum is appropriate here, or that a reference vs a pointer makes more sense given the rest of the code. I'm sure a clever machine learning algorithm could figure that out with a corpus as large as Google's. Maybe. But no tool like that works today. And not strangely at all, Google does accept "what clang-tidy does" as the canonical way of formatting text. But readability at Google is far more than just formatting. Readability is frustrating and annoying, but more than just lint.

dlubarov 5y ago
> I know of no automated tools available today that can determine if an identifier is accurately and usefully named. Naming isn't very language-specific though [*], and poor naming should be flagged in coding interviews. Any Google engineer should generally have good naming, and should be able to critique others' naming in any language. [*] Granted there are some language-specific naming conventions, like ! and ? in Ruby methods. But I'd say the majority of languages don't have important naming conventions, and those that do often have lints for them.
- vkou 5y ago
  > Naming isn't very language-specific though [*], and poor naming should be flagged in coding interviews. I'm not going to turn a candidate away because they use shorthand names when writing code under time pressure on a whiteboard.
  - Jensson 5y ago
    This discussion wasn't about hiring but about code reviews. If you use bad names in your code then the reviewer is correct when they tell you to make better names.
- compiler-guy 5y ago
  "poor naming should be flagged in coding interviews" Exactly! And Readability process is exactly the training Google uses to ensure someone knows how to look for this issue, and that someone actually is looking for this issue in code reviews. There is plenty about the Readability process I don't like (particularly that one has to get it through a fairly artificial process), but checking for things like the above (which I just use as one easily understood example) isn't something that happens automatically in an organization as large as Google, with as many engineers as Google. A common story on HackerNews is just how bad the average programmer is, how crummy code they produce. Taking steps to ensure they do it better is a good thing. We can argue about the process, for sure, and there are many things I would love to change about it. But "yeah, that should be done in code reviews" is exactly the idea here.

gravypod 5y ago

> So the rules can be codified sufficiently to test people on, but they can't be codified for a computer? Small note: readability isn't a test or quiz you take (asterisk). It's obtained by merging code in the language you want readability for. If you merge code for a language often and the reviewers have very few style-based questions for the code then you will get readability fairly quickly. > The only one that sounds more difficult to codify is telling people of the existence of duplicate functions. But as someone who contributes to the linux kernel, I can tell you right now that the only way that works reliably is to have a very large pool of reviewers. Very experienced engineers frequently miss what people are doing in other parts of the source base, the name might not be what they expect, etc, etc, etc. A better example would be knowing when you should use `const std::string&`, `std::string_view` or `char*`. Example: https://abseil.io/tips/1 https://abseil.io/tips/1 The best readability advice I have recieved has been: 1. Direct "I was confused by X" or "The recommended way to do A is using B", etc 2. Reasoned: "std::string_view is more efficient and clearer in intention than char ptr, it also improves type safety as it is read only and clear about ownership" 3. Linked to source material where examples are given totw or other examples in the code.

anyfoo 5y ago

> So the rules can be codified sufficiently to test people on, but they can't be codified for a computer? I mean, given the halting problem alone, and the absence of general AI, yes, I'd say that... I'm not sure what to tell you otherwise. I've worked at a place with such strong coding style guidelines, and even though I personally did not agree with every individual point, I accepted the tradeoff because being able to count on consistency in a very large code base was extremely helpful.