In my favorite IDE (Eclipse CDT at the moment) there's a feature to automatically apply a configurable codestyle to your currently opened file. I'd like to implement something like it for the godot editor also. It was suggested to me to open an issue to discuss this.
The idea is as follows, there would be a project setting for several code-style related items such as parenthesis hugging of variables. When set to 'hugging' it would change
def my_func ( stuff )
to def my_func(stuff)
when requested through a keyboard shortcut.
Things to consider:
Question I have are: would this be interesting for upstream, if so should I write it in gdscript or make changes to the editor?
I'd strongly suggest changing the editor itself. Variable naming might be a bit tricky. Personally I guess this is definitely a "nice to have" feature, just nothing important. So if you want it, just implement it for yourself and submit it for the others as a proof of concept and/or finished PR?
Also rather than creating some custom config format or settings, how about relying on something existing such as EditorConfig, making the whole thing interchangeable in case someone wants to edit files in some other editor instead?
Code formatter is always good thing
Other things to consider:
#comment
vs # comment
, line wrapping etc.1+x
vs 1 + x
variable naming (case) snake_case CamelCase etc.
It's more like refactoring feature (that would be useful too
Of course every option should be configurable.
After working with Go, Crystal and other languages that enforce one formatting style I have to say it's a best option IMHO.
Of course every option should be configurable
Or you could go the gofmt
way of creating one style guide and only enforce that if this is enabled.
Pros:
Cons:
Non-configurable formatting is sort of vendor lock-in ("Our way or no way") and a way of torture IMO :laughing:. Configurable formatting with format on demand capability will be more appropriate. When you get some code you just press format button and you can use it. Readability is a very weak argument for a language using space count as block limiter.
Any news on this topic? I'd very much like to see a formatter like gofmt
that only allows one style.
Hey will we get this? One of the problem is that in which langauge should we implement this in
Excuse me @reduz @akien-mga , is it possible for we get this feature? Or at least where can one start from if they want to contribute it.
It's low priority so we don't plan to work on it ourselves in the near future, but any contributor is welcome to give it a try. I think the best approach would be to do a GDScript editor plugin for that, though it might imply exposing additional features to the plugin interface to handle the code editor.
Note that it's only relevant for GDScript (and maybe the shading language in a separate project). For C#, there are plenty of well established formatters already available in the ecosystem.
oh man, was searching and finally found this issue (thank goodness i didn't make a new thread xD)
but anyway, i use crystal lang for my game server. and i use the vscode plugin here. each time we save, the code is automatically formatted. it makes it sooooo nice! especially when copying code into the editor. it's like having a "friend" that helps you out whenever you do ctrl+s (gives motivation and encouragement to the developer). i'd also argue this kind of feature increases productivity tenfold and it also tidy's up your code. although, with that said... gdscript will only run if you got everything perfect already (a lot more stricter than crystal-lang), so you will slowly overtime get trained to make sure your code is right. with that said though, while using gdscript and you copy code from online or whatnot, it's very annoying to do the indents yourself, etc.
i'm def in favor of an auto formatter on save (toggleable in the editor). would be amazing imo
would be to do a GDScript editor plugin for that
ayee @willnationsdev 馃ぃ馃憣
Of course every option should be configurable
Or you could go the
gofmt
way of creating one style guide and only enforce that if this is enabled.Pros:
* Consistent code everywhere * No discussion about code style and other small quibbles * Once it becomes the norm, code of others becomes very easy to read as all code in the ecosystem uses the same style
Cons:
* Only one style, so maybe you don't get your preferred flavor of whatever setting/style
If someone is interested, I've created exactly such a formatter called gdformat
https://github.com/Scony/godot-gdscript-toolkit/. It's a python script, so it is portable. I'll try to integrate it to Godot IDE soon.
@Scony I saw your plugin today and I thought to myself it would be really awesome if I could make a Gdscript EditorPlugin that will integrate and run your linter and formatter. But I was not really sure how could I call a python script from inside of Gdscript. Maybe a C compiled version of your linter and formatter would be possible. But again I need to look into how to call such external scripts. But you got a really awesome tool for formatting and I will try my best to see what I can do to add into editor itself.
EDIT: Ok so I just found a way to do it. Run external program will try my best on what I can do.
On my repo,you can find a fork of the godot sources with a specific branch (gdscript_format_updated) that contains a gdscript formater that is integrated into the script editor.
It's based on the Frugs's work but updated and merged with the 3.2 branch of Godot as often as possible.
You can grab the sources, build and use it.
That's what I'm doing now for my godot works, using a 3.2 built version with an included auto formater
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
Most helpful comment
Or you could go the
gofmt
way of creating one style guide and only enforce that if this is enabled.Pros:
Cons: