Skip to content

Linter

Jump to bottom
Benjamin edited this page Mar 14, 2020 · 8 revisions

File Linter

Built in is a VB6 linter. While not necessary, it is somewhat recommended.

Linting the code will help you spot issues that may slow down your conversion. Many do not matter a whole lot, such as line indent, whether you have the variable on the Next of a For ... Next loop.

In general, the code converter should run without it, but some rules, such as the WITH handling, are often better handled in the native code, rather than letting these things migrate to C# and trying to introduce a temp variable name "on the fly".

Rule Customization

If you want to configure the linter, you can configure individual rules in the file modLinter.LintAbbr(), and follow the instructions in the comment there. Ultimately, if the function return "", the rule is ignored.

Lint Ignore

Some files, especially API or type heavy modules, should not be linted.

To ignore a file, use one of the following:

  • '@NO-LINT - Ignores the entire file for linting.
  • '@NO-LINT-IDNT - Ignore all rules in the IDNT (Indent) category.

To ignore linting (either completely or for a single rule) on a line, simply place the comment at the end of the line to ignore on.

Dim UnTypedVariable '@NO-LINT-TYPE - Ignores the lack of a variable type. - But, of course, why not just declare it As Variant?

Manual Linting

The preferred way to use the linter is from the Immediate window.

To manually lint a file, in the Immediate window from the converter project, type:

?LintFile("C:\path\to\yourfile.frm")

This will output lint messages only to a message box. To output results to the Immediate Window, try

?LintFile("C:\path\to\yourfile.frm", ".")

To lint an entire folder, type:

?LintFolder("C:\Your\Folder\Path")

Additionally, you can lint individual types with:

  • ?LintModules
  • ?LintForms
  • ?LintClasses

Why Lint?

Why should you lint your code? Why spend what could be considerable effort for no ultimate change? Here are some reasons...

  • It may take some time to lint your code, but consider this. VB6 did not require variable type declarations. Neither does C#, technically. But, would you rather have your C# code litered with dynamic variables, where things weren't typed in VB6 (and hence used variant types everywhere), or would you like to make a maintainable, durable codebase, free from a bunch of unnecessary type-casts and work-arounds, just because you wanted to save some startup time.
  • Additionally, you might not like to have to specify ByVal on all the variables everywhere, but do you really want to have a bunch of pass-by-ref calls in C#, where it was easy to simply be lazier in your VB6 code?
  • Yes, it does take time, but it is worth it.
  • The good thing about this is, no matter what upgrade path you pursue, this will make any upgrade easier, in the long run.
  • Linting your existing VB6 code shouldn't break your existing code. Be careful. Go slowly. But, in the end, you code should behave identically as to pre-linting.

Linter Quality

This is not a fast linter. It is merely a mostly functional one. If you find errors in it, feel free to submit an issue and/or a code-segment which lints incorrectly. It is by no means error-free, but it worked for out large project, ultimately.

Project Config

Be sure to Configure your project first. Even when running from the Immediate Window, the configuration should be respected.

Clone this wiki locally