3 ms·

Very well written, and funny too. I wish there was a way to automate some of the lower buckets too. Things like "project consistency" (see his "12 buckets"), f

Very well written, and funny too. I wish there was a way to automate some of the lower buckets too. Things like "project consistency" (see his "12 buckets"), for instance, are incredibly important to me personally. IMHO, code should be written so that there is no visible personal style, so that newcomers and new engineers are able to follow what's going on regardless of who wrote it. A human can easily determine if the style of code is the same, or if it's different. It'd be fantastic if a machine could do the same.

giraffe_lady 5y ago
> IMHO, code should be written so that there is no visible personal style This seems reasonable at first but depending what you mean by visible personal style can get you into the weeds so fast. You can end up creating a process where no minor, specific improvements or experiments are tolerated unless they can be justified as generalizable improvements for the whole org. > , so that newcomers and new engineers are able to follow what's going on regardless of who wrote it This isn't actually related to the first thing? There's some overlap sure but for the most part whether it's in camel case or snake doesn't affect my ability to comprehend it.
- binwiederhier 5y ago
  > This isn't actually related to the first thing? There's some overlap sure but for the most part whether it's in camel case or snake doesn't affect my ability to comprehend it. This isn't about camel case or snake case. It's about the overall structure and look and feel of the code. When you know that public functions are at the top, constants are in a certain place, and where package-level comments are; and when you know that important abstractions and models are defined in one file, and their implementations in separate files; and so on. Basically, it's the combination of all the tiny things that make code look and feel like they belong. This is similar to when people say "this is not idiomatic Go". What I'm saying is pretty much "idiomatic for this project/company/product/team". Write it so that it matches the rest of the project. That helps people navigate and read your code, which is the most important thing.

giraffe_lady 5y ago

> IMHO, code should be written so that there is no visible personal style This seems reasonable at first but depending what you mean by visible personal style can get you into the weeds so fast. You can end up creating a process where no minor, specific improvements or experiments are tolerated unless they can be justified as generalizable improvements for the whole org. > , so that newcomers and new engineers are able to follow what's going on regardless of who wrote it This isn't actually related to the first thing? There's some overlap sure but for the most part whether it's in camel case or snake doesn't affect my ability to comprehend it.

binwiederhier 5y ago
> This isn't actually related to the first thing? There's some overlap sure but for the most part whether it's in camel case or snake doesn't affect my ability to comprehend it. This isn't about camel case or snake case. It's about the overall structure and look and feel of the code. When you know that public functions are at the top, constants are in a certain place, and where package-level comments are; and when you know that important abstractions and models are defined in one file, and their implementations in separate files; and so on. Basically, it's the combination of all the tiny things that make code look and feel like they belong. This is similar to when people say "this is not idiomatic Go". What I'm saying is pretty much "idiomatic for this project/company/product/team". Write it so that it matches the rest of the project. That helps people navigate and read your code, which is the most important thing.