Decompiler should not generate symbolic names with "Name" suffix

[majastrz]

Is your feature request related to a problem? Please describe. The decompiler often generates resource symbolic name with the Name suffix which causes the actual variables holding the resource name to have the _var suffix.

It's fairly easy to fix it by renaming the symbols as follows, but it is tedious in large templates:

Describe the solution you'd like Whenever possible, we should drop the "Name" suffix from the generated symbolic names. Then the existing logic will stop adding the _var suffix.

[mattias-fjellstrom]

It seems like if you have the following ARM-template

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "variables": {
    "storageAccountName": "mystorageaccount"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2021-06-01",
      "name": "[variables('storageAccountName')]",
      "location": "northeurope",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2"
    }
  ]
}

It gets decompiled into the following Bicep

var storageAccountName_var = 'mystorageaccount'

resource storageAccountName 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName_var
  location: 'northeurope'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

The Name part in the resource symbolic name actually comes from the fact that I named my variable to storageAccountName. If I change my ARM-template and rename the variable to dummy I get the following Bicep

var dummy_var = 'mystorageaccount'

resource dummy 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: dummy_var
  location: 'northeurope'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

So this issue is not necessarily about dropping the Name suffix from the generated symbolic name, it's more about deciding on where should the symbolic name come from in this case? I mean, the Name just happens to be there because it is common to have the name set by a variable and it is common to named these variables something like storageAccountName.

I tested what happens if I instead use a parameter called storageAccountName, in this case the generated Bicep is

param storageAccountName string = 'mystorageaccount'

resource storageAccountName_resource 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: 'northeurope'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

Here the parameter keeps it's name as is, but the resource logical name gets an added suffix (because parameters are handled before resources in the code)

[StephenWeatherford]

Dupe of #1591