I’ve created a config file for the AStyle (it’s very cool tool for file formatting and indentation).
It includes almost all JUCE’s coding standards’ formatting rules.
I think it could be convenient especially for the newcomers to JUCE.
It’s very easy to use:
astyle --options="juce_astyle.options" [path to the file]
If we want to perform recursive formatting we should use “-r” flag and wildcard: astyle --options="juce_astyle.options" "*.cpp" -r
To perform a trial run with no changes to the files, add “–dry-run” flag. astyle --options="juce_astyle.options" "*.cpp" -r --dry-run
I’m running AppCode and I’ve been using this astyle formatting in conjunction with some simple regex patterns (which fix some things that AppCode doesn’t have options to format). I have it setup that whenever I make a commit in git, it’ll ask me if I want to format the edited source files, could be useful to others. Haven’t tested it thoroughly but it’s been working well so far.
pre-commit (place this script executable in project_dir/.git/hooks) see http://githooks.com/
#!/bin/bash
echo ""
git diff --name-only --cached | cat | grep -E '.cpp|.h'
echo ""
echo "format the above files to JUCE standards? (y/n)"
# connect keyboard -> stdin
exec < /dev/tty
read -s -n1 c
# close connection keyboard -> stdin
exec <&-
if [[ $c != y ]]; then
exit 0
fi
"juce-format-added-changes.sh"
Anyone know any way to prevent this from auto expanding switch statements to multiple lines? Take for example some code from the Projucer. This options file will automatically break the following lines up so that each statements after the case is on a new line? Is there a way to ignore switch statements?
I’ve been holding out, not wanting to sound stupid, but…
I’ve seen a few coding styles over the years, and I get and have adopted JUCE’s style with one exception…the space between a function name and the open parentheses.
runMyFunction ();
vs
runMyFunction();
To me, the space makes no sense because it isn’t a function without the pair of parentheses. Same goes for a switch(foo) statement.
Even the forum’s code auto formatting seems to agree with me…lol.
From Astyle manual: Blocks of code can be disabled using “off” and “on” tags. The tags are included in the source file as comments. The comment may be a C comment (/* … */) or a C++ line comment (//). The tag must be included in a single line comment. If the comment exceeds one line the indent tag will be ignored. Additional information can be included with the tag. Example: