Disabling warnings in D-Scanner: looking for suggestions

[Dennis]

I actively try to reduce D-scanner warnings in my projects 
appearing in the VS Code 'problems' tab (using your super-handy 
code-d extension, thanks for developing that!), but I never put 
comments in to suppress warnings.

They clutter up the code and I don't like them.

I know code-d supports the `// stfu` comment, which is almost as 
simple and unobtrusive as it gets, but even then I don't like the 
idea of someone else reading my code and wondering where those 
random profanities come from. Explicit @suppress comments are 
clearer in that regard, but they are long and tie your code to 
dscanner. You might need an additional set of suppression 
comments once you add a different linting tool, and it only gets 
worse.

That's why I only resolve warnings by modifying the offending 
code:

> calling foo without side effects discards return value of type 
> string, prepend a cast(void) if intentional

This particular warning is generated by dub, but dscanner gives a 
similar warning for unused parameters, though code-d only grays 
unused parameters instead of adding a problem.

In any case, casting by void is great since it is short and 
clear, and it transfers to any linting tool. It even transfers to 
C/C++ in this case. Other examples how I remove warnings are:

> Local imports should specify the symbols being imported to 
> avoid hiding local symbols

Specify the symbols or move the import to global scope.

> Undocumented public declaration

Add a documentation comment to the declaration (even just an 
empty /// ) or make it private / package.

> Line longer than 120 characters

Split up the line.

> Variable name does not match style guidelines

Change the capitalization. You can make an alias to the symbol 
with the original capitalization since aliases don't have a style 
rule.

There are a few warnings that can't easily be solved however, 
like the 'dscanner.suspicious.unmodified' you mentioned.
```
int x; // dscanner says: 'could be declared const'
increment(x); // but this function takes arguments by ref!
x += 0; // so should I just do some bogus 'modification'?
```

Ideally, I would like to the language to support `increment(ref 
x)` on the call site (similar to what you suggest:
https://forum.dlang.org/thread/dhiwpttqeaxctdzczxlb@forum.dlang.org).
Though we can't count on that.

My most hated warning is:

> Avoid subtracting from '.length' as it may be unsigned.

Sometimes you can rewrite e.g. (x < a.length-1) to (x + 1 < 
a.length), but other times there's simply no way around this, and 
I need to access element `a.length-1`, and Dscanner can't see 
it's in side an `if (a.length > 0)` block.

Regarding your suggestions:

> more fully featured comments to disable

I don't know what 'fully featured' means. Can you elaborate this 
one?

> using a Java-like @suppress UDA in the source code to mark 
> blocks and statements
> ...
> - easy to ignore warnings for whole classes (bad practice)

I'm not sure I would call surpressing warnings at large scale is 
bad practice per se.
When I open e.g. bindbc-opengl, dscanner gives 1000 problems of 
'undocumented public declarations', while of course there aren't 
1000 individual cases where documentaiton was forgotten. It is 
just raw bindings with no documentation, that is only worth 
mentioning once. Also a huge large array literal might spawn a 
lot of warnings that every line is too long, really cluttering up 
the problems tab.

> extending D's pragma like in C# for pragma(warning, disable, 
> [warning codes]) and pragma(warning, restore, [warning codes])

In that case, I feel the warnings should be defined by the 
language and not the linting tool.

> What kind of suppression system would you prefer to see in 
> D-Scanner, what would you prefer not to see? Open for 
> suggestions.

As I said, ideally you never have to suppress warnings.
I know sometimes it's hard to get around it, but I don't know a 
good solution for that unfortunately.