Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code-style formatter in editor #7392

Closed
hpvb opened this issue Dec 29, 2016 · 13 comments
Closed

Code-style formatter in editor #7392

hpvb opened this issue Dec 29, 2016 · 13 comments

Comments

@hpvb
Copy link
Member

hpvb commented Dec 29, 2016

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:

  • parenthesis hugging for function parameters, function calls, etc. (separate options)
  • spacing for lists (1,2,3) vs (1, 2, 3)
  • line wrapping
  • variable naming (case) snake_case CamelCase etc.
  • hash formatting (multiple lines?)

Question I have are: would this be interesting for upstream, if so should I write it in gdscript or make changes to the editor?

@MarioLiebisch
Copy link
Contributor

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?

@TeddyDD
Copy link

TeddyDD commented Apr 5, 2017

Code formatter is always good thing
Other things to consider:

  • comments formatting #comment vs # comment, line wrapping etc.
  • math operations 1+x vs 1 + x
  • add newline at the end of file (git likes it)

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.

@mhilbrunner
Copy link
Member

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

@hubbyist
Copy link

Non-configurable formatting is sort of vendor lock-in ("Our way or no way") and a way of torture IMO 😆. 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.

@Bios-Marcel
Copy link

Any news on this topic? I'd very much like to see a formatter like gofmt that only allows one style.

@michaellee8
Copy link

Hey will we get this? One of the problem is that in which langauge should we implement this in

@michaellee8
Copy link

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.

@akien-mga
Copy link
Member

akien-mga commented Nov 29, 2018

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.

@girng
Copy link

girng commented Dec 2, 2018

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 🤣👌

@Scony
Copy link
Contributor

Scony commented Feb 5, 2020

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.

@vickylance
Copy link

vickylance commented Apr 26, 2020

@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.

@LaurentOngaro
Copy link

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

@akien-mga
Copy link
Member

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests