3 ms·

> Even though it’s not meant to be hand-edited, this can impact code readability and maintainability This kind of implies that the generated code is being chec

by danans 2y ago

> Even though it’s not meant to be hand-edited, this can impact code readability and maintainability This kind of implies that the generated code is being checked into a repo. While that works, it's not the way things are done at Google, where protobuf codegen happens at build time, and generated code is placed in a temporary build/dist directory. Either way , you shouldn't need to do any maintenance on protobuf generated code, whether you add it to a repo or use it as a temporary build artifact.

kelnos 2y ago
I agree, and that's how I do things, but I still think the readability of generated code is important. I want to know what generated code is doing, and more often than I'd like, I run into problems with it, and need to trace through it to find out what's going on. Sometimes this just makes it easier to submit a thorough bug report (or even a patch) to the maintainer of the codegen tool, but often by tracing through what's going wrong I can find a way to work around the problem. Readability is definitely something I look for in generated code.
forrestthewoods 2y ago
> This kind of implies that the generated code is being checked into a repo. I wouldn’t say that. I observe uncommitted generated code all the time. Sometimes I want to read the code just to understand how the heck something works. Or I step into it in a debugger. I definitely believe that generated code should be pleasant to read.
jeeyoungk 2y ago
The Go ecosystem (at least in the public) heavily encourages committing all generated code as go code is meant to be functional via a simple `go get`. Even a popular project like Kubernetes is full of generated protobufs committed in the codebase.
- febusravenga 2y ago
  Next ecosystem totally forgot what proper makefile is... And they arguing it is innovative and pragmatic. Sad.
  - SR2Z 2y ago
    If you've ever seen a Makefile longer than 1000 lines you'd get it too

by danans 2y ago

kelnos 2y ago

I agree, and that's how I do things, but I still think the readability of generated code is important. I want to know what generated code is doing, and more often than I'd like, I run into problems with it, and need to trace through it to find out what's going on. Sometimes this just makes it easier to submit a thorough bug report (or even a patch) to the maintainer of the codegen tool, but often by tracing through what's going wrong I can find a way to work around the problem. Readability is definitely something I look for in generated code.

forrestthewoods 2y ago

> This kind of implies that the generated code is being checked into a repo. I wouldn’t say that. I observe uncommitted generated code all the time. Sometimes I want to read the code just to understand how the heck something works. Or I step into it in a debugger. I definitely believe that generated code should be pleasant to read.

jeeyoungk 2y ago

The Go ecosystem (at least in the public) heavily encourages committing all generated code as go code is meant to be functional via a simple `go get`. Even a popular project like Kubernetes is full of generated protobufs committed in the codebase.

febusravenga 2y ago
Next ecosystem totally forgot what proper makefile is... And they arguing it is innovative and pragmatic. Sad.
- SR2Z 2y ago
  If you've ever seen a Makefile longer than 1000 lines you'd get it too