dartfmt about three.dart HOT 8 CLOSED

Thank you for addressing this. The goal is to make three.dart as idiomatic as possible so we should strive to follow the style guide as much as possible.

As you guessed most of the incoherences come from the three.js styling but since we have dartfmt we should follow its rules (but with --line-length 120 at least... I've stopped programming on VTs some years ago :P)

Regarding the for => forEach I'm all for it (map, filter, reduce whenever you can ;))

One thing to keep in mind is that we'll have to arrange for these change to be merged only after closing relevant PR otherwise we'll find ourselves in rebasing/merging hell.

from three.dart.

@nelsonsilva The only PR left is yours, but it looks like there's only a minor modification to one file.

I'd like to move forward with this, but I'd like to know whether I should try to break it up into smaller commits, or just go for it all at once.

Thoughts?

from three.dart.

@beatgammit We can move forward without merging my PR. It's WIP and the PR is there just for tracking and discussion. GLTF is a moving target.

from three.dart.

@nelsonsilva - Should I break it up into smaller commits, or just do it all at once?

from three.dart.

I think this should be done all at once as breaking it up doesn't add any value to the history.
What do you guys think about using --line-length 120 ? @financecoding @robsilv @johsin18

from three.dart.

I'm in favor of line length 120.

from three.dart.

+1 for 120

Also, i'm looking forward to this update. I had to turn off "formatting on save" in Dart editor to make my last pull request not include a bunch of formatting changes. It will be nice when all of the code in three.dart is properly formatted and changing settings in dart editor is no longer necessary.

from three.dart.

Ok, I have a pull-request ready, but it should probably wait until all pull-requests that don't just add files are resolved.

from three.dart.