This is a creation in Article, where the information may have evolved or changed. The introduction of '//go:generate ' makes it easier for the go language to integrate automated code generation tools during the build process. ' Stringer ' makes it easier to write duplicate code, while the ' Yacc ' and ' ragel ' programs make it possible to generate an optimized parser. On [Gogeneratetools] (https://github.com/golang/go/wiki/GoGenerateTools) You can find an incomplete list of such tools. * * Flag automatically generated code * *. In order for the build tool to recognize the automatically generated code, you must use a comment that conforms to the following regular expression: "' ^//code generated." The text must be in the first line of the formatted go file comment. This comment must precede all the '/* */' comments and ' package ' statements, but cannot be attached to ' package ' statements. This is similar to the rules for build tags. Files with this header format will be ignored by the Go Lint tool and will be collapsed by default in GitHub PR and diff. Of course, it would be nice if you could indicate the tools and parameters that generated the code. * * use ' _ ' * * where needed. You can simplify your code-generation steps by assigning to ' _ ' the packages, methods, package-level variables, and variables that you might not actually use. **GOFMT your generated code * *. Formatted code can make it easier to read code when debugging a problem. Similarly, because the editor can gofmt the file after it has been saved to prevent accidental whitespace changes, you might need to use some linter tools on the generated code, at least for the sake of checking correctness. Lint warnings are acceptable (although not encouraged), because machine-generated code is always as standard as no one would write. * * Guaranteed OUTPUT certainty * *. The multiple-run tool should have the same output without changing the input. Do not rely on map ordering or add uncertainties in the output. And I have different opinions about using timestamps. Although it is good to know that the file is generated, there should be no output when the file does not change. * * Keep the readability of diffs * *. This is related to the previous article. People submit code to the warehouse. If they generate a new file, they will be able to see the changes in the file and its effect on the generated code when there is an update. I met some happy things (or more frustrating things) when I used the Code auto-generation tool myself.。 So what do you want the code auto-generation tool to do?
via:https://medium.com/@dgryski/five-nice-things-for-machine-generated-code-5335e67c1e36
Author: Damian Gryski Translator: Alfred-zhong proofreading: Rxcai
This article by GCTT original compilation, go language Chinese network honor launches
This article was originally translated by GCTT and the Go Language Chinese network. Also want to join the ranks of translators, for open source to do some of their own contribution? Welcome to join Gctt!
Translation work and translations are published only for the purpose of learning and communication, translation work in accordance with the provisions of the CC-BY-NC-SA agreement, if our work has violated your interests, please contact us promptly.
Welcome to the CC-BY-NC-SA agreement, please mark and keep the original/translation link and author/translator information in the text.
The article only represents the author's knowledge and views, if there are different points of view, please line up downstairs to spit groove
688 Reads
