A common issue I encounter is the "abuse" of global/suite/test variables. I would like the ability to mark these "abused" variables as *DEPRECATED* so I can slowly get rid of it.

Context

One might write keywords like this:

*** Settings ***
Library    RequestsLibrary
Library    Collections

*** Variables ***
${JSON}

*** Keywords ***
Make Amazing API Call
    ${response} =    Get    https://example.com/amazing/path
    VAR    ${JSON} =    ${response.json()}    scope=TEST

Get Meaningful Data From API
    ${meaningful_data} =    Get From Dictionary    ${JSON}    something
    RETURN    ${meaningful_data}

In this example, the ${JSON} test variable is, what I would call, "abusing" test variables. I would much prefer something like this:

*** Settings ***
Library    RequestsLibrary
Library    Collections

*** Keywords ***
Make Amazing API Call
    ${response} =    Get    https://example.com/amazing/path
    VAR    ${json} =    ${response.json()}    scope=TEST
    RETURN    ${json}

Get Meaningful Data From API
    [Arguments]    ${response_json}
    ${meaningful_data} =    Get From Dictionary    ${response_json}    something
    RETURN    ${meaningful_data}

One of the core reasons I don't like the first example, is that it's really hard to figure out where the ${JSON} variable is used. That makes it hard to refactor the first example into the second example. Especially if the people working on the codebase have worked like this for a long time.

Some readers may now think: Who would do something like this? I asked. It appears that people who are not into coding don't see the issue until well after they've reached the point of no return. To them, it's a convenient feature of Robot. It's a working solution to the problem they have right now. They don't know that they should worry about long-term maintainability. Or they straight up don't care about maintainability.

There is nothing wrong with global/suite/test variables by themselves. They are great for many things. However, they are bad replacements for RETURN and [Arguments].

Whelp, I got side-tracked a bit. Back to the point:

Proposal

To help people fix these kinds of things, it would be nice if we can mark the ${JSON} variable as *DEPRECATED*. This deprecation marker can then serve as a reminder to stop using the variable in new keywords/tests.

The deprecation marker can also be useful if you want to phase out some global project config.

The deprecation marker only applies to the variables section.

Syntax

This could maybe look something like:

*** Variables ***
# *DEPRECATED*
${JSON}

# *DEPRECATED* No longer used, replace usage with returned local variables.
${RESPONSE}

and/or

*** Variables ***
${JSON}    # *DEPRECATED*
${RESPONSE}    # *DEPRECATED* No longer used, replace usage with returned local variables.

Expected behavior

Runtime

When running a test
If Robot encounters a usage of the deprecated variable (e.g. Get From Dictionary ${JSON} something)
Then log a warning similar to the one used for deprecated keywords

When running a test
If Robot encounters un update to the variable value (e.g. VAR ${JSON} ... scope=TEST)
Then log a warning similar to the one used for deprecated keywords

Test log

Display the warning messages created during runtime. (existing functionality)

Libdoc documentation

When a deprecated variable is used as an argument default
Then render it with strikethrough similar to when using deprecated keywords (e.g. some_argument = ${JSON})

or

Do nothing. Libdoc does not concern itself with global variables, why start now.

IDE

(outside the scope of this repository)

When editing a file
If the language server encounters a usage of the deprecated variable (e.g. Get From Dictionary ${JSON} something)
Then render it with strikethrough similar to when using deprecated keywords (e.g. ${JSON} or $JSON)

When editing a file
If the language server encounters un update to the variable value (e.g. VAR ${JSON} ... scope=TEST)
Then render it with strikethrough similar to when using deprecated keywords (e.g. ${JSON} or $JSON)

Linter

(outside the scope of this repository)

When linting a file
If the linter encounters a usage of the deprecated variable (e.g. Get From Dictionary ${JSON} something)
Raise an issue (as warning?)

When linting a file
If the linter encounters un update to the variable value (e.g. VAR ${JSON} ... scope=TEST)
Raise an issue (as error?)