Re: Code Alignment Visual Studio
Vilma Steiert
Based on principles borrowed from mathematics and other disciplines, code alignment gives extra meaning to your code by lining up similar data in columns. This is something we do naturally when working with tables and spreadsheets, but unfortunately it doesn't get applied to code often enough.
Formatting makes source code easier to read by human beings. By enforcing particular rules and conventions such as line spacing, indents, and spacing around operators, the code becomes more visually organized and comprehensible. You can view an example on the autopep8 page. Keep in mind, formatting doesn't affect the functionality of the code itself.
Linting helps to prevent errors by analyzing code for common syntactical, stylistic, and functional errors and unconventional programming practices. Although there is a little overlap between formatting and linting, the two capabilities are complementary.
Note: If you don't find your preferred formatter in the table above or in the Marketplace, you can add support for it via an extension. You can use the Python Extension Template to integrate new Python tools into VS Code.
Alternatively, you can set it as the default formatter for all Python files by setting "editor.defaultFormatter" in your User settings.json file, under a [python] scope. You can open settings.json with the Preferences: Open User Settings (JSON) command.
In order to set a formatter extension as an import sorter, you can set your preference under "editor.codeActionsOnSave" in your User settings.json file or your Workspace settings.json file, under a [python] scope. You can open these settings.json files using the Preferences: Open User Settings (JSON) and Preferences: Open Workspace Settings (JSON) commands respectively. This will enable import sorting on save for all Python files.
Note: If you don't find your preferred formatter listed above, you can add support via an extension. The Python Extension Template makes it easy to integrate new Python tools into VS Code.
Next, be sure to add this configuration setting. Then the Format Document command and keys will work with Salesforce Apex. I believe you can also accomplish the same thing with the Java language support, but this is working for me.
Simply, it's needed to install uncrustify plugin on visual studio code that give you the possibility to indent apex code using the shortcut CTRL + ALT + F .The linked guide explains how to proceed step by step
I didn't want to use Crustify, which most of the other answers suggested. However, I came across the following for sfdx and VS Code. It is prettier, with a (possibly community contributed) Apex plugin:
However, the default settings for the standard Rust code formatting tool rustfmt will convert tabs into spaces when re-formatting your code. Presumably VS Code is set up to use rustfmt on your Rust files. If you wish to use tabs, you can reconfigure rustfmt to do so (see the documentation).
VS Code lets you control text indentation and whether you'd like to use spaces or tab stops. By default, VS Code inserts spaces and uses 4 spaces per Tab key. If you'd like to use another default, you can modify the editor.insertSpaces and editor.tabSize settings.
This is one reason why I think that rustfmt, gofmt etc are so useful: not because of their immediate formatting function (although that is of course useful too), but because it just settles such useless debates by biasing the entire ecosystem toward one or the other.
This is also why OP shouldn't use tabs: not because it can't be done, but because their project will be one of the handful, vs the literal thousands of extant Rust projects. And if they ever accept commits from others, that will be an additional source of friction.
Regardless of one's preference for tabs or spaces (again, a superlatively useless debate if you ask me, to the point that the comedy series Silicon Valley actually satirized this), going against the ecosystem norms is generally a bad idea, and makes life harder for all involved.
The main argument for using tabs for indentation is accessibility. The ability to distinguish indentation space from word separator space makes life easier for people who need assistive technologies or simply different indentation levels to read code.
The solution then, for people in need of accessibility, is to alter the way those indentation spaces are rendered to the person in question by various utilities.
That is, it's a (collection of) purely local setting(s), and it should be 100% invisible to the outside world.
I wonder how valid that accessibility argument is? Do we have any blind programmers here who can comment on that? I ask because I have met blind programmers and none of them brought up any issue with indentation, spaces vs tabs. Also, at least in theory, those indentation and spaces/tabs have no meaning, the compiler is blind to them. It's a different matter with crazy syntax like Python though.
Most modern IDEs are capable of automatically detecting indent style and width. In my experience, the cases where they guess incorrectly are vanishingly small. Tabs and spaces as indentation are treated practically the same these days[1], including keyboard navigation and rendering.
As far as I know, the strongest argument for tabs is provided by Elastic Tabstops. And this is the strongest argument against that. However, it's not entirely clear whether the performance really can't be improved, because no one has put that much effort into optimization.
The "spaces camp" values the simplicity of plain text. They like having this grid of cells they can draw things on with glyphs[1], which are laid out equally for everyone. The contents of the grid are then parsed into AST by the programming language of their choice, or transformed isomorphically by the formatter of their choice. To this end, things like syntax highlighting, type hint, indentation marker, ligature, etc. are not the first-class features of the code.
The "tabs camp" values the extensibility of rich text. They like parsing code style features like indentations and brackets as markups, of which style is determined by project and editor configuration, like how HTML style is determined by CSS and browser. This separation of style and structure, done consistently, would leave nothing for the formatter to do.
Both options have their own upsides and downsides. Plain text is easier to develop tooling for, and it can be sent anywhere without causing compatibility problems. Rich text, on the other hand, can better adjust to different people with their different visual preferences.
For now, the "spaces camp" have successfully captured the "don't care camp" by the virtue of requiring less editor configuration. Meanwhile, the "tabs camp" have struggled for the same reason XML did. Even though the expressive power of rich text is useful in some specific contexts, the amount of upfront and continuous investment required has made it unattractive to most people. Ultimately, the situation was not about which paradigm would result in a higher productivity, but rather "perfect is the enemy of good".
If you are using a decent editor (you don't even need an IDE, just a real text editor that's not Notepad), it will autoindent for you and respect tab stops, even if there are literal spaces in the source code.
As far as I know, the strongest argument for tabs is provided by Elastic Tabstops . And this is the strongest argument against that. However, it's not entirely clear whether the performance really can't be improved, because no one has put that much effort into optimization.
Algorithmically speaking, it's rather easy to make it performant -- you just need to store the elastic tab positions in an appropriate data structure rather than recompute everything from scratch on every keystroke. The comment on the ticket also says as much, they just think it would be "insanely hard to keep consistent and add a huge maintainance burden", but I don't think that's really true.
In Visual Studio 2022 version 17.9 Preview 1, we have introduced a Memory Layout view, which unveils the memory arrangement of classes, structs, and unions. This feature is particularly valuable for optimizing memory layouts. Users can now visualize padding, offsets, and sizes of all data members within their types.
These features will greatly benefit C++ developers in improving code efficiency and comprehension, making it easier to work with memory management and data structures. Download Visual Studio now to leverage these enhancements in your C++ development process.
As far as my knowledge goes, .NET non primitive datatype sizes are undefined before runtime and is also platform specific. The CLR decides sizes at runtime, or at least not before JIT.
But with the new NativeAOT form of building it may actually be hard coded in the binary (?), but that may still be for value types only. I am still not sure about that for reference types (classes), because the GC allocates and frees those dynamically.
1. I would really appreciate it also showing the whole class/struct size in the .VCMemoryLayout window since I find myself switching away from the layout view just to review the tooltip for the struct to see its overall size again. I realize I could probably scroll to the last member and add values but a simple bit of text at the top would save a lot of effort.
d3342ee215