0

I maintain some analysers for C# code and TypeScript code. Those analysers shall skip generated code.

In C# it is rather simple because such class has attrribute System.CodeDom.Compiler.GeneratedCode.

But how about TypeScript? How can I generically recognize that the code is generated?

Tomas Kubes
  • 23,880
  • 18
  • 111
  • 148
  • I think the only way you could do this is if the code generator puts some comments like `// @begin-generated-code` and `// @end-generated-code` to delimit the code that your analyser should ignore. Otherwise you could use heuristics like ignoring variables and functions whose names match some pattern. – kaya3 Feb 28 '22 at 17:06
  • In C# this attribute is widelly used by 3rd party tool where you have no control over such generation. – Tomas Kubes Feb 28 '22 at 17:10

3 Answers3

2

There is no generic way of doing this - generated typescript code can be indistinguishable from any other piece of typescript code.

The normal way of getting a tool to ignore generate TS code is to have to configuration that says which files/directories to ignore. This config is specific to each tool. For example eslint can use a .eslintignore file which might contain a lines like

dist
**/generated
matt helliwell
  • 2,574
  • 16
  • 24
0

Name the generated file as something like "myClientAuto.ts", and have the static code analysis to skip files with suffix Auto, or some prefix if you want. For generated C#, even the System.CodeDom.Compiler.GeneratedCode is not really needed, if you put the generated codes in its own csproj project, and just opt out the project from CA.

ZZZ
  • 2,752
  • 2
  • 25
  • 37
-3

Recognizing generated TypeScript code isn't as standardized as it is in C#. However, there are a few common practices and indicators you can look for:

  1. Comments: Many code generators include comments in the generated code to indicate that it's auto-generated. Look for comments that include terms like "generated", "auto-generated", "do not modify", etc.

  2. File Header Comments: Often, generated files have a header comment at the top of the file that explains the source and purpose of the generated code. This can be a good indicator.

  3. Specific Naming Conventions: Some code generators might follow a specific naming convention for files, classes, or variables that indicates they are generated. For example, if all generated classes have a specific prefix or suffix.

  4. Presence of Libraries or Tools: If the generated code relies on certain libraries, tools, or dependencies that you can identify, that might indicate that it's generated.

  5. Comparison with Source: If you have access to the source files, you can compare them with the generated files. Generated code often lacks human-readable formatting and may have repetitive patterns that are absent in hand-written code.

  6. Timestamps: Generated files might have creation timestamps that can help identify them.

Given that TypeScript code generation practices can vary widely, you might need to use a combination of these indicators. Keep in mind that no single method is foolproof, and it's possible that you might encounter some generated code that doesn't adhere to the typical patterns.

As TypeScript doesn't have a standardized attribute like System.CodeDom.Compiler.GeneratedCode, you'll likely need to tailor your approach based on your specific context and the code generation practices you encounter.

Nabeel Hassan
  • 1
  • 9