Code generators do our hard work. But we don’t need them anymore. Free lines of code A few years ago working in the industry I took part on the demo of a programming product in which a or was used. The presenter boasted of writing less code, leaving the machine to write the text for her. Based on the templates that she was declaring. The seduction argument consisted of writing less code. Today we know that this approach is completely wrong. wizard code generator If we have to tell the machine what the meta code is, it is because we are not being declarative enough. Photo by Phil Desforges on Unsplash There are several reasons: a) We have not yet reached the level of abstraction and we have to teach the interpreter to make syntactic manipulations on our models. If there is a certain redundancy, the usual approach would be to model that redundancy by searching in real world against the abstract concept we should match. b) Some code generators are based on the (almost always incorrect) excuse that generated code is faster than the more declarative one used when including an indirection or abstraction. The performance argument almost always loses its support against a real benchmark. As a counterpart we can argue that to read or debug a function in general, the bunch of computer generated code confuses the novice programmer (and the experienced one wastes lots of time). What is (wrong with) software? Currently, human time is more valuable and scarce than machine time. c) Some programming languages ​​impose arbitrary type restrictions that are only saved with intermediate code generation such as Java generics or templates in c++. These are language limitations and not model restrictions. Non-declarative languages ​​like C++ or Java offer us with tools like or that Templates Generics look different but are similar. < :isEmpty() {
 }
}; Linked_List<T>::append(T value) {
 generic_node<T> *new_node = generic_node<T>;
} template > <T>: class T bool Linked_List void new Photo by Shahadat Rahman on Unsplash d) The interpreter uses meta-programming to resolve these hints, although this is discouraged, among other reasons, for leaving obscure references, almost impossible to refactor and easily erasable by mistake. Laziness Chapter I: Meta-Programming e) The code generated with Wizards or with meta-programming is much darker, much more difficult to follow and violates the principle of failing fast because it does not usually know how to defend itself against possible invalid constructions. We have the choice not to use it if we want to build good software models. f) The code generated by the wizards, templates and is of very low quality. It is not usually documented and generates coupling as it is a repetitive . In case of finding an error in one of the generated fragments and, due to said coupling, we will have to correct it in multiple places violating the Fail Fast Philosophy, Explained automatic code generation tools cut&paste DRY principle. Coupling: The One and Only Software Designing Problem g) The generated code has little added value, and often encourages bad design practices like automatic generation. setters and getters Nude Models - Part I : Setters h) Finally, if computers can make inferences about the repetition of our design patterns, it is because we are not contributing the creative part (and for now not replicable) and we will be out of work in the short-term. (Most) Programmers are losing our jobs very soon The solution is on the usual shelf Given the symptom of finding a pattern that is repeated in our code, the diagnosis is almost always the same: There is an abstraction or generalization in the domain of the problem that we have not yet discovered. The trivial solution is to go, with the help of our favorite domain expert, to discover what that encompasses repetition or pattern that the wizard or template did not allow us to discover. is the real-world concept Photo by Volodymyr Hryshchenko on Unsplash Conclusions Dynamic code generators were a fad at a time when productivity was measured based on the lines of code generated. To avoid them, we must stay true to the rule of bijection and look for abstractions within the real world in the problem domain. Part of the objective of this series of articles is to generate spaces for debate and discussion on software design. We look forward to comments and suggestions on this article.

BUNCH

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Nominated for 2022 - HackerNoon Contributor of the Year - Refactoring

Nominated for 2022 - HackerNoon Contributor of the Year - Quality Assurance

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Nominated for 2022 - HackerNoon Contributor of the Year - Machine Learning

Nominated for 2022 - HackerNoon Contributor of the Year - Clean Code

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - the Greatest Storyteller

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Portfolio

Software Engineer

Too Long; Didn't Read

Laziness Chapter II: Code Wizards

Laziness Chapter II: Code Wizards

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

From Helpful to Harmful: How AI Recommendations Destroyed My OS

How ADRs Help Engineering Teams Cut Costs and Reduce Technical Debt Over Time

The Boredom Paradox: How Risk-Averse Engineering Built the Internet's Most Resilient Companies

Clean Code: Interfaces in Go - Why Small Is Beautiful [Part 3]

Spotify Study Flags Key Limits in Measuring Information Flow in Code Reviews

Spotify Study Maps How Information Spreads Through Code Reviews

From Helpful to Harmful: How AI Recommendations Destroyed My OS

How ADRs Help Engineering Teams Cut Costs and Reduce Technical Debt Over Time

The Boredom Paradox: How Risk-Averse Engineering Built the Internet's Most Resilient Companies

Clean Code: Interfaces in Go - Why Small Is Beautiful [Part 3]

Spotify Study Flags Key Limits in Measuring Information Flow in Code Reviews

Spotify Study Maps How Information Spreads Through Code Reviews

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps