@Pietro Di Leo 
If you find Wireshark intimidating you can use the Web Gateway's HTTP trace facility. If you're using Wireshark and the server is on the same machine as VS Code select the loopback capture device and add an http filter. This will help you filter out unwanted packets. If you use the Web Gateway's HTTP Trace, you can simply turn it on, attempt to save the class, turn the trace off, and then click refresh to see all the packets. You will be looking for a PUT request to the /api/atelier/v#/doc/<class_name> endpoint. We want to see what the full response is to that request.

Studio is still available from the WRC as an independent download. See this DC post for more details. I am happy to help you get VS Code working, but to know what is wrong I will need to see your code-workpsace file, server connection info and possibly a network trace since VS Code talks to IRIS via HTTP(S). If you're more comfortable doing that in private you can open a WRC case and they will help you. You can link this post there so they have more context. This feature has existed in VS Code for 4.5+ years so I think there's some sort of configuration issue and not a product defect. Also, any feedback on how we can make VS Code better can be communicated to WRC, your account team, or by posting an issue on GitHub.

Are you using client-side editing (your ObjectScript classes are in a local folder that you have open in VS Code), or server-side editing (files are edited directly on the server, like Studio)? This is important so I can give you the best advice for troubleshooting the problem. Which steps in the documentation did you follow to get this set up?

@Paul Hula 
Do you have in the InterSystems ObjectScript Extension Pack installed? The InterSystems Language Server provides autocomplete support for class names and class members. If you already have the extensions installed and are still experiencing this issue then you probably don't have a server connection configured. The documentation for doing so can be found here.

VS Code allows you to change the colors used in the editor via Themes. Documentation is here. If you're on Windows you can also load your custom colors from Studio using the "Load Studio Syntax Colors" command.

Hi Joel, thanks for the feedback! There's no reason why you couldn't have Prettier format your local files. It just won't work as well as it does for other languages because there's isn't an ObjectScript plugin (AFAIK), and some elements of class definitions (everything that isn't implementation code) is re-rendered after syncing with the server. I have looked at the "objectscriptQuality" rules before to see if there's anything that I should add to the Language Server extension and I came to the conclusion that it wasn't doing anything that was really valuable. If there are specific rules that you find useful I'd be happy to hear your thoughts, but I've resisted adding a bunch of Diagnostics/formatting options for "code style" issues  because many ObjectScript developers don't agree on them!

Thanks for the detailed post @Joel Solon! #Dim isn't necessary for many system percent variables because the Language Server already knows their types. The full list currently supported can be found here. %sqlcontext is not one of them, so please open a feature request to add that and any others that I might have missed. I also wanted to note that coming soon is support for variables passed by reference as method arguments, so even that case won't require #Dim.
 

Integration with the BPL and DTL will be available when the new versions of those editors are released. The VS Code integration will support client-side editing as well. The Rule Editor integration already does so.

You're mixing up what we mean by "client-side editing" and what git-source-control does to maintain files in Git. In VS Code, client-side editing means "editing files on my locla file system directly". git-source-control is used when you're editing files directly on an IRIS server, and it handles the projection to the file system so Git can pick up changes. These are fundamentally different development models that shouldn't be mixed. Mixing them can lead to files being out of sync and changes being lost or overwritten.

1. Connecting to any server is pretty easy so I'm not sure why we'd need to add a special case for dockerized IRIS.

2. Can you elaborate please? Are you referring to the lack of BPL/DTL UI integration?

3. This is incorrect. git-source-control is a server-side source control solution. You must use server-side editing to work with it. We do not and will not support the use of server-side source control classes with local files.

Hi @Gramen Tontchev, for non-classes and routines on the local file system the main extension needs to use the file name to determine the name of the document on the server. There's no guarantee that all "other" document types will have the name of the document stored in the text, and even if that were true, it would be very difficult for the extension to know how to extract that info from each one. I have a PR open that will improve the client-side editing workflow, but this behavior remains the same. 

TL;DR: The name of the file must match the name of the document on the server.

@David Hockenbroch 
This functionality exists in VS Code. It's provided by the Language Server extension. Here's the description of the feature from that extension's README:

To invoke the command, right-click in a blank line of a class definition body and select the Override Class Members row in the menu that appears. The command will insert the selected class member definition(s) at the cursor position where the command was invoked.