First pass with clang-format #198
Conversation
| } | ||
|
|
||
| //============================================================================== | ||
| void AppHarness::watch (const juce::File& f) | ||
| void AppHarness::watch(const juce::File& f) |
There was a problem hiding this comment.
Are we trying to stick to the juce style guide? If so I think non-empty parens would have a preceding space (i.e. SpaceBeforeParens: NonEmptyParentheses instead of SpaceBeforeParens: ControlStatements)
There was a problem hiding this comment.
Heh. Hopefully we don't need to fully comply .... I hate that leading space.
There was a problem hiding this comment.
Haha, such a can of worms this business. I'm in the not caring so long as a tool is doing it for me camp.
There was a problem hiding this comment.
Hah, I'll admit, I'm also not a fan of that leading space. Generally though, I too am in the "i don't care let's just standardize it" camp.
I think generally if we can reach a small consensus of "yea looks good enough for me" then we should go for it
| return (this->timeoutsManager.get()->*method)(_args.arguments[0]); | ||
| } | ||
| })); | ||
| registerNativeProperty(name, juce::var::NativeFunction([this, name, method](const juce::var::NativeFunctionArgs& _args) -> juce::var { |
There was a problem hiding this comment.
I'm not a big fan of the way this indents the inline lambda here... is there a way to nudge this back as it was?
| duk_destroy_heap | ||
| ); | ||
| duk_create_heap(nullptr, nullptr, nullptr, nullptr, detail::fatalErrorHandler), | ||
| duk_destroy_heap); |
There was a problem hiding this comment.
Also not a huge fan of pulling this trailing comma up. But my clang-format knowledge is weak here :)
There was a problem hiding this comment.
Ah man: https://reviews.llvm.org/D33029
Big change, but all this really does is use the clang-format file that @JoshMarler mentioned in #24 with juce-like defaults and run it against
blueprint/core/*Let me know what you think!