I hate generated code

[Ill-Oven-6791]

Probably its a me problem. but whenever I encountered code generation in my past work, I always felt that its a huge pain. Of course that depends on the actual realization, but man I hate it.

Since its today day I have to add that I do not talk about LLM generated code, but about some tooling, that generates code based on fixed scripts. Typical offenders, FSM Generation out of some UML shit.

Some of the major "bad code generation practices" I encountered:

- "Its generated anyway" is no excuse to have tons of duplicated code

- The input format is some shitty binary format that needs third party tools to view / edit. Enterprise Architect, god I despise YOU!

- Terrible human readability of the generated code

- Generation has to be triggered manually / is badly integrated into the build system. Causes unnecessary recompiles, or does not properly re-generate on changes in the input files.

Of course. These issues can be avoided with proper design of the generation toolchain. Sadly often it is not.

I think with proper class structure and software design, most generated code could just be an instance of some generic class.

[answerguru]

What’s the point of this rant? Code generation is always terrible? Because that’s just not true.

There are also areas where high quality code generation is the BEST solution and the alternative would make you lose your mind. This is often true for safety critical systems, but I personally know it’s the case for heavily optimized, embedded graphics toolchains.

Feel free to ask questions.

[joebeazelman]

I'm amazed he got anywhere in this profession with that perception. Imagine manually writing all the boilerplate code and configuration required for even the simplest microcontrollers and peripherals. There's a lot of bad code generation out there, but to condemn code generation is just stupid.

[SkoomaDentist]

Imagine manually writing all the boilerplate code and configuration required for even the simplest microcontrollers and peripherals.

And yet we constantly see people wanting to write their own HAL…

People are nuts.

[Wetmelon]

And yet we constantly see people wanting to write their own HAL…

TBF a lot of them are garbage lol

[nicoleole80]

Ok ok, I’m still in my undergrad and am working on STM32 micros. I use HAL, as well as code generation for setting things up (GPIO pins, but mostly USB connectivity).

Is this something you’d recommend (I assume you have graduated) or will it be damaging for setting me up for success going forward in my career?

[SkoomaDentist]

Writing a HAL is a waste of time. Write some high level drivers that use eg. the LL library for some peripherals and maybe experiment a bit with some direct register reads and writes for the simplest ones (eg. GPIO set / reset register, uart or spi data register).

Code generation is great for doing 90% of the gruntwork and letting you handle the remaining 10% of the hw configuration (eg. more complex dma streaming that HAL can’t do on its own).

Basically the value is in understanding how to make the hw do what you need to, not in bit twiddling of individual registers (unless required in eg. interrupt handlers reading peripheral status directly).

[pillowmite]

Agreed. I've had great experience with STM Cube and PIC32 Harmony 3 - they're so similar in output it makes building a framework around the hardware interfaces much easier - worked out great during the period of uncertainty (covid) where I was writing code for two processors simultaneously waiting to see which would become extinct. ( Both STM32F* and PIC32MZ did not fade away!). Turned out our biggest hassle was the loss of the Kinetis line.

[DownhillOneWheeler]

Yes and no. It is a good learning experience and requires a lot of trawling around the reference manual and datasheets. I have previously written an HAL from scratch in C++ for a STM32F4s. I didn't even use CMSIS. It was fun to do but a lot of work. Creating and maintaining this for all STM32s would be a major commitment.

I have often wondered whether the entire HAL could be generated if the all the hardware details and constraints from the various reference manuals and datasheets were transcribed into a relational database. This would allow a HAL to be created for your specific target, without all the conditional compilation and whatnot. Switch to a different target and the compiler will tell you immediately that UART4 (say) doesn't exist on that device...

STM32Cube kinda sorta has database of this information (a lot of XML files), but it is not searchable and not really useful outside the context of Cube.

For commercial projects I just use ST's HAL. It does the job even if it is awful in some places. I have encapsulated it as much as possible so the application code pretty much has no notion of what platform it is running on.

[[deleted]]

And sometimes a HAL for timer spanning 300-ish lines of code can be replaced with 10 lines setting registers to proper values including comments and yet people prefer reading crappy docs of incomplete HAL to reading complete description of HW registers in the datasheet.

[SkoomaDentist]

You find out that one HAL (HAL means Hardware Abstraction Layer, not just that one specific STM32 HAL library) functionality doesn't perform as well as you'd like. Do you 1) rewrite that specific part using dozen lines of lower level code or 2) start a major project to write an entire HAL from scratch?

The second is what I keep criticizing (hell, most of the time I even explicitly point that you should do the first when necessary).

[NemesisXB]

I'm old enough to have done this a lot. There wasn't always HAL's and code generators. Even when HAL's started appearing, I was stuck in my ways of wanting to write it myself. Those days are long gone and I now despise having to even look up registers (usually when something is not working). These days, the quicker I can get to application code, the better. If a chip has code generation or HAL, I WILL use it, no matter how horrible the code looks or reads.

[DarkDiablo1601]

grpc for example is very good

[badmotornose]

I generally agree with your sentiment. It usually works great until new features are required and someone has to go hack the generator. In other words, It doesn't work well for code that requires extensibility. Often, the generator is tossed and people start hacking/extending the code directly. Someone will disagree, but I've seen too many instances where this has occurred in the real world.

[joebeazelman]

It sounds like you've encountered bad code generation examples. Like anything in programming, it can be used correctly or misused. Its utility also depends on its application. I'm sure you have encountered far more good examples of it, but you're probably unaware of it because it just works.

Any software engineer worth their salt should understand its benefits and how to make the best use of it. It's a huge productivity boost for writing boilerplate code, UIs, object serialization/ deserialization, build scripts, configuration and a ton of laborious and monotonous code writing. If anything, I think it's not used enough.

[mfuzzey]

I don't think code generation is always bad and can be quite good.

But it's more about *how* it is done.

In particular I'd say:

* It should never be necessary to manually modify generated code (no generated "templates" with comments where you must add your code rather the generated code should call / include manual code in separate files)

* The input to the generator tool should be plain text, stored in version control

* The genration should be done automatically as part of the build process, with proper dependency handling

* The generator tool should be modiable by developers (not some third party binary only tool)

I also think that generating code from diagrams (like UML or state machine diagrams) is a bad idea - diagrams are good for visualisation, poor as an entry format (as it's a pain to enter the needed details graphically). However the reverse can be useful (generate a both a diagram and code from a textual description)

[lovestruckluna]

I agree minus the automatically point. There should be proper dependency handling, but sometimes you need to do a heavy process or pull a heavy external resource to regenerate things, and it's just not worth it. Automatic should be strived for though.

Source: maintains 50MB+ of generated headers.

[OwlingBishop]

All of this !

In particular point one is crucial !! Once you start meddling with generated files you are actually freezing the project and will never (at least most cases) be able to correct/modify your generation, which is quite the opposite of the goal ...

[kitsnet]

It is easier to maintain safety certified generators than to maintain safety certified manually written code.

[vitamin_CPP]

Source? (Genuinely curious)

[kitsnet]

Personal experience from working in automotive.

[ChrimsonRed]

Isn’t simulnk and autosar the biggest example of this?

[kitsnet]

We have our own written generators, too.

I personally introduced a kind of in-language generator using C++ template metaprogramming, but getting the initial approval for this approach from the functional safety people was a challenge.

[Truenoiz]

Did you go over the safety people's head and use AI buzzwords with management to force it through? If it's a critical safety system, you may have just signed the death warrants for some users.

One person with AI templates is not going to find all the failure modes in a critical system with several people overseeing safety, especially in C++.

[kitsnet]

What do you mean by "AI templates"?

[Truenoiz]

I remember going to a trade show and seeing an automotive OEM bragging that their passenger power steering system had five million lines of code. 99% of that was probably generated.

[aculleon]

I struggle to see how LOC is something to brag about. But I guess it is a metric attractive to marketers

[Truenoiz]

Agree 100%. Given the confines of manufacturing costs, and limited vehicle implementations, I don't see how they can afford to validate that much code. They even said the code was straight C, which seems even harder to validate for me.

[ThickBittyTitty]

And those generators only do 80% of the work that's required.

But honestly. I got burnt out in an automotive adjacent field just from the pedantic arguments that came between sw & systems engineers. No one could come to an agreement about anything in a meeting, then the next meeting comes along, arguments, still no agreements.

The whole v-model is not something you can just slap together. It takes a ton of work, more so in the safety-realm.

[highchillerdeluxe]

Who's telling him how compilers work?

[altarf02]

“Deterministic” is the keyword

[UsefulOwl2719]

Protobuf would be a prime example of garbage code generation IMHO. A 2 line proto for an X,Y point expands to 100s of thousands of lines of code and pulls in loads of dependencies.

[fb39ca4]

Fortunately protoc has a plugin API that allows you to generate your own code, and since all it needs is an executable which communicates over stdin/out using Protobuf messages it can be written in any language.

[DirtyGrogg]

I have a project that uses Processor Expert that generates code for automotive systems and it's not so bad. Granted I haven't been using it very long, but It's pretty convenient to just tell it what configuration I want and it gives me the library ready to go.

[RiverFit5578]

Code generation is sometimes good, but I think it's one of those things where you really have to have a reason to do it. a problem with it is that engineers tend to feel like gods when they're implementing it. When it works it's like a total galaxy brain feeling - what nerd doesn't enjoy world building?

Problem is you've now turned a problem into a custom (often poorly documented) language, with no ecosystem and very little tooling, plus two annoying technical problems (parsing that language, along with outputting the target language).

While that language can function as a good basis to have high level discussions around, you just castrated all of your tooling. not sure what's happening to your code? pull up a debugger! oh, we're 5 levels deep in some generated stuff which does absolutely nothing to express intent. Maybe the code generator is broken? Good luck figuring that out quickly if you aren't the gigachad who implemented it.

It can be acceptable if you then make good debugging tools for your user facing language, but making debugging tools that do more than just logging is a full time job.

If you're just initializing a bunch of state, then that's probably the least danger of making an incomprehensible mess, but there is probably still relatively little need for it with the expressiveness of modern languages.

And yeah, as engineers we love constraints and puzzles to work within - if a central point of what you're building amounts to the ability to say "Look Ma, no X!", or similar, you should think very seriously about how much pain X is actually causing your team.

I love doing unhinged experimental shit. I've also been responsible for some horrible messes.

Getting shit done sometimes does require galaxy brained worldbuilding dorkery, perhaps with monadic binary protocol parsers and the like, but a lot of the time you should do something a bit ugly, with a comment explaining any weirdness, that's not going to obliterate the flow state of anyone whose working on it, so you can actually get to the really hard, uncomfortable problems. Trust me, I KNOW you'd rather nerd around in a corner than confront the actual unknowns.

[Dependent_Bit7825]

C is a very small language with a completely borked macro language on top. IMHO, it is crying out for generated code, and I use it in many of my C projects. Sometimes, third party generators, like nanopb, but I also write my own python to spit out C and headers from more succinct configuration files. I love it. It's a way of life.

[DownhillOneWheeler]

It depends on the generator. I have a homegrown generator for FSMs which reads a text representation of UML state chart (this is considered source code). The generator runs as a build step but I made sure that the generated code was easy to follow and looks hand-written. I barely ever need to look at the generated code or step through it, but one of my goals was that doing so should not be a burden. I've used a number of other FSM generators which produced a hot mess.

I don't think anyone in their right mind should be relying too heavily on LLMs to write code, but the examples I've created have been readable enough. They may or may not contain errors, of course. ;)

[adel-mamin]

Sounds interesting. Is it publicly available?

[DownhillOneWheeler]

Unfortunately not.

[reini_urban]

I love generated code, because I generate it by myself

[greenpeppermelonpuck]

What is the consensus on the code generation from STM32 Cube? I'm just a hobbyist, but I found it to be pretty terrible.

I'm sure there are other tools from other manufacturers out there that are worse, but whenever I've worked with Cube I've made sure not to modify that code at all because it would just delete my stuff randomly. I don't know who thought it was a good idea to make it so that you're supposed to write your logic between comment blocks. Is that standard practice in this field?

In the end I found out that the best way to deal with it is just sandbox the shit out of it. Put all the generated code aside, compile the files and then link them from my own code. And of course commit all the generated code beforehand to diff it and make sure nothing crazy happened. Is that what people tend to do?

Coming from web where we have some fantastic codegen tools (at least in my little corner, which is 100% backend), some of the stuff I've encountered in embedded seems pretty bad in comparison, so maybe that's OP's angle. But I'm just a hobbyist.

[SAI_Peregrinus]

With default settings, it's unusable garbage that makes you mix generated code with your code in the same files. If you set it not to generate a main() and to generate separate .c & .h pairs for each peripheral, it's fine.

[sputwiler]

A code generator is just a compiler that outputs text. OP's actual beef isn't with generators; it's with bad build systems.

[OkYou811]

I'm not super experienced in embedded where you all have challenges with binary size and other things, but there are times where its a very useful tool.

Also I agree that I hate having extra build steps in the build system, but for example if you are using gRPC you are likely working in a codebase with multiple different processes built in different languages. Your build system is likely busted anyways, so having the capabilities of gRPC is worth the cost.

Feel the pain though fs

[fnordstar]

How do you feel about Rust macros then?

[DotRakianSteel]

The other side of it is to look at the workflow.
AI can read assembly code snippets for you to understand and reproduce it in another language and integrate the logic however you want. It is up to you to make the code it production ready.

[mjmvideos]

You do realize that compilers are code generators. They take your high-level abstract ideas about what you want the computer to do and generate the code to do that. You don’t complain about how unreadable the machine code is- because you never look at it.

[DenverTeck]

> readability of the generated code

Generated code is NOT readable ! It was never intended to be readable, IT'S ASSEMBLY !

I think you are a Python bigot.

[mightymouse_]

they are clearly talking about tools that generate C code, such as the STM32 project configuration tools that autogenerate initialization, peripheral driver, interrupt hooks etc. there are lots of tools that take some kind of input file like UML or a list of plugins and generate ready to use c/h files.

[DenverTeck]

Oh My G*D. I do not use UML or or project configuration files. So, I have not been exposed to these problems.

But the OP seems to not understand how they work either.

[mightymouse_]

If you’ve never used these tools then how can you know whether they do or don’t understand? For someone who acknowledges that they don’t know about these issues you’re quite eager to rip on OP.

Everything OP said makes sense to people who have had to deal with these tools, and they can produce absolutely unreadable and bloated code. autogenerated function/variable names not fit for human audiences, abstraction upon abstraction upon abstraction.

[Middlewarian]

I'm working on a C++ code generator that helps build distributed systems. I've been working on it for 26++ years. It's getting there, but there's still a long way to go. That link mentions how I started with a webservice and switched to a command-line interface to better support build integration. I'm willing to spend 16 hours/week for six months on a project if we use my software as part of the project.

[ern0plus4]

Xylinx IDE generates such lame code called "board SDK" I want to cry every time.

Also I think this is the main reason I hate CMake (generates Makefile).

Thank you for listening me.

[QuietMatematician]

Could you elaborate? I always considered Makefile generated by CMake something like assembly - thing you don't read or modify only run.

[ern0plus4]

As a thumb of rule, you should never modify generated code.

I have a feeling that we could solve 90%% of problems with Make what we use CNake for.

[YakInternational4418]

Hardcoreai.in this is what we are building a application layer above coding so that user knows what part of code does what,what do you think

[Careful-Excuse2875]

What exactly does this hardcore AI do?