A new bracket style option, "style=mozilla", has been added. It uses linux brackets with opening brackets broken from classes, structs, enums, and function definitions. Brackets are attached to everything else, including namespaces, arrays, and statements within a function.
A new option, "break-one-line-headers" will break a header (if, while, else, etc...) from a following statement on the same line. There is more information in the "Formatting Options" section of the documentation.
A new option, "pad-comma", will add a space following a comma. The option "pad-oper" has not been changed and will also add a space following a comma.
A new option, "indent-continuation", will add extra indents to continuation lines following a line that ends with an opening paren '(' or an assignment '='. This includes function definitions and declarations. There is more information in the "Indentation Options" section of the documentation.
All spaces before a comma are now removed. Use the "disable formatting" comment tags if there are arrays with vertical alignment where this is not wanted.
A correction has been made to the Pico style indentation of one line blocks. And there is a fix to always compute the indentation of a one line block. If you use Pico style with an indentation greater than 2, you may have a lot of changes made to the code.
New Objective-C options "pad-return-type" and "unpad-return-type" will add or remove space padding after the Objective-C return type in a method definition. They are described in the "Objective-C" section of the documentation.
New Objective-C options "pad-param-type" and "unpad-param-type" will add or remove space padding after the Objective-C parameter type in a method definition. They are described in the "Objective-C" section of the documentation.
The Objective-C "align-method-colon" option is now applied to Objective-C method calls in addition to method declarations and definitions. The method call colons will be aligned, if possible. If this option is not declared, the method calls will align on the first keyword. See the astyle documentation for an example.
The Objective-C "align-method-colon" has been changed for long keywords. For multi-line arguments when the first keyword is shorter than the others the colons are aligned on the longest line instead of the first line. The alignment includes room for the indentation. This aligns all colons after the first line for a better appearance. Arguments that do not have a short keyword in the first line will remain the same. This style conforms to the Google Objective-C style.
Processing for C++14 single-quote digit separators has been added.
Translations have been added for Bulgarian, Estonian, Greek, Hungarian, Norwegian, and Romanian. The translations were done with an automated translation program, Google Translate, so they may not be the best translation possible. The translations are at the end of ASLocalizer.cpp in the form of an English-Translation pair. If you correct a translation, send the source as a bug report and it will be included in the next release. To add a language, see "Internationalization" in the "General Information" section of the documentation.
The C# example, in the Developer Information has been updated. Objects for the AStyle callback functions are no longer required. These have been removed and the delegates used instead.
There is a new C# example in the Developer Information, that loads the AStyle shared library using explicit linking. This allows the shared library name to be dynamically changed so that a program compiled with "Any CPU" can load either a 32-bit or 64-bit shared library at run-time. It runs on both Windows and Linux.
Visual Studio Code, the text editor from Microsoft, has an Artistic Style extension. The extension runs from the Visual Studio Code menu and is controlled by entries in the User Settings file. It can be installed from Visual Studio Code. There are links to the websites on the Artistic Style Links page.
Thanks to David Faure for his contribution.
The following are additional topics.
The Artistic Style software license has changed. It is now under the MIT license. This is a permissive license which can be used in proprietary software and does NOT require modified Artistic Style source code be made available. It is compatible with the GNU General Public License (GPL) and most other software licenses. The change was made to remove restrictions on using the software and to make it available for any project that wants to use it.
In order to be used on both Linux and Windows, the ASLocalizer.cpp UTF-8 file in Artistic Style does not contain a Byte Order Mark (BOM). With Visual Studio 2015 there has been a change in how UTF-8 files without a BOM are processed. The new procedure is described here. It affects only the language translations in the ".exe" file. The shared libraries and static libraries are not affected. It is necessary only if you are using a translation other than English.
In addition to the "auto detect" option in Tools > Options... > Text Editor > General, an additional compiler option is required. The option "/source‑charset:utf‑8" must be added to the project properties at C++ > Command Line > Additional Options. Since the non‑unicode files in Artistic Style are ASCII, the option can be applied to the entire project instead of just one file. This option has been added in the files distributed with Artistic Style. There is also a new "/validate‑charset" option, which gets turned on automatically with the above option. This switch enables the validation of the UTF-8 input files.
This compiler option was not available until Update 2 of Visual Studio. If you are using an earlier version of 2015, a BOM should be added to the file using File > "Advanced Save Options". Change the encoding to "Unicode (UTF-8 with signature) - Codepage 65001".
In the above "Visual C++ Team Blog" Microsoft mentions that in a future major release of the compiler, they would like to change the default handling of BOM-less files to assume UTF-8.
Visual Studio 2013 and 2015 have an Edit option "Align Assignments" that will align assignment operators across multiple lines. There is also an extension named "Code alignment" that will align the code on other items as well. Other development environments may have something similar. These will selectively align the data and allow for customization of the format.
These options and extensions can be used with Artistic Style. If you choose to do this, the space padding will be maintained and the alignment will be preserved.
Coding style, or programming style, is a set of rules or guidelines used when writing the source code. It is often claimed that following a particular programming style will help in reading and understanding source code conforming to the style, and help to avoid introducing errors.
This Artistic Style distribution has a new "file" folder containing AStyle options files for various coding styles. Using the option files will give approximately the indicated coding style. The files can be used as they are, or modified as desired.
There is a new GUI test program AStyleWx that uses wxWidgets. This replaces the old AStyleWin program. AStyleWx is multi-platform and has more features simply because they are easier to implement with wxWidgets.
It has download files and a website in a new sub-project directory of Artistic Style. The downloads contain source code, documentation, and scripts. The Windows download contains an executable. The needed Artistic Style source files are included.
It is licensed under the MIT license. The source code may be used and modified for any purpose you choose. Developers using Artistic Style in another project may use any part of AStyleWx in their project. The modified source code does NOT need to be made available to others.
The executable in the Windows distribution package is now compiled with a Visual Studio version that will no longer work on Windows XP. Beginning with Visual Studio 2012, auto-vectorization tries to make loops run faster by automatically vectorizing the code. Auto-vectorization is on by default, and there are no compiler switches, #pragmas, or hints to disable it. It uses SSE instructions not available in Windows XP. Microsoft ended support and updates for XP on April 8, 2014, and the usage share percentage continues to decrease.
To compile on a non-XP machine for use on XP, using a compiler other than Visual Studio should always produce an XP executable. Using Visual Studio 2010 or earlier should always produce an XP executable. If you are using Visual Studio 2012, 2013, or 2015 on a non-XP machine, do the following for the Artistic Style configuration you want to use:
In newer releases of Visual Studio 2015, the "Universal CRT" files have been moved. There is a notification here. To compile using XP there may need to be additional include and library directories added. If the compile gets errors add the appropriate directories to the project properties.
Release 2.05.1 (December 2014) is a maintenance release and no new features were added. A list of changes is in the Release Notes. The following information is for the original 2.05 release.
A new bracket style option, "style=vtk", has been added. It uses indented brackets, like Whitesmith, except opening brackets for classes, functions, and methods are not indented. A complete description of the VTK style is available at the "Visualization Toolkit" website (http://www.vtk.org/).
A new preprocessor indent option "indent-preproc-block" will indent preprocessor block statements one additional indent. The block must be top-level, or included within a namespace, and there are restrictions on what can be indented. The option is described in the "Indentation Options" section of the documentation.
A new option, "dry-run", will run Artistic Style without updating the files. The report will be output as usual.
Formatting of source code may now be disabled for portions of a program by embedding special comment tags in the program. These are described in a new "Disable Formatting" section of the documentation. They work the same as in other formatters. There are tags to disable formatting for a block of code, and a tag to disable formatting of a single line. This should allow any custom formatting to be retained.
The product version number has been added to the filename of shared library (DLL) compiles. This will allow multiple versions of a shared library on the same system without conflicts.
An attribute '__attribute__ ((visibility ("default")))' has been added to exported functions on Linux shared libraries. This allows the option "-fvisibility=hidden" to be used on dynamic library compiles. According to the GNU documentation, "Using this feature can very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute."
Improvements have been made in the formatting of C++11 uniform initializers (enclosed by brackets). The opening bracket will not be space padded unless it is padded initially. The closing bracket will not be broken from the final line unless it is broken initially. And the known problems with uniform initializers in class constructors have been fixed.
The Windows compiler definition ASTYLE_NO_VCX (no Visual Studio exports) has been changed to ASTYLE_NO_EXPORTS. It is sometimes needed for static libraries on other compilers to prevent error and warning messages.
Qt and Boost macros foreach, forever, Q_FOREACH, and Q_FOREVER will now be recognized as headers.
The main documentation for Artistic Style is in HTML format. Until now there has not been a way to display it from the astyle console program. A new option, "html" or "-!" will display the help documentation in the default browser. This documentation is more complete than the astyle "help" option. It includes examples, and has an index for easier navigation. Since astyle is typically run from a script this should allow an easy way to access the documentation. The option is available only from the command line.
The new "html" option assumes the documentation is installed in the standard install path. This is /usr/share/doc/astyle/html for Linux and the path %programfiles%\AStyle\doc for Windows. If it is installed to a different directory, use the variation "html=<actual_install_path>astyle.html. This option can also be used to open other HTML files. More information is in the "Command Line Only" section of the documentation.
The "html" option on Linux uses the script "xdg-open" from the install package "xdg-utils" to find the default browser. This should be available on most systems. If it is not available on your system you can file a bug report requesting a change. It would be helpful if you could determine how it is done before filing the report. You can also file a bug report if the documentation is not installed to the above "default" directories. The HTML documentation takes quite a bit of effort to maintain and I would like to make it easily available.
The "help" option has been changed to send the output to stdout instead of stderr. This will allow piping and redirection of the output. A common way to use the option on Linux is "astyle --help | less", which will page the display. The "version" option has also been changed to stdout.
A shared library error handler argument has been changed from "char*" to "const char*". In some cases this may cause compile errors in a user program until the references have been changed.
The "Indent Style" topic on Wikipedia states that the "ANSI" style refers to K&R style brackets and not Allman style as used by Artistic Style. The option "style=ansi" is therefore being deprecated and will be removed in a future release. Use one of the other long options instead (style=allman, style=bsd, or style=break).
Some of the documentation has been removed from the distribution package. It still contains all files needed to install and run Artistic Style. The included files can be used without an Internet connection.
There are now build files available for Xcode on Mac. The makefile is still available for those who want it. Both now use the LLVM Clang compiler. There has been a change to the makefile debug locations to make them similar to Xcode. The "Install Instructions" have been updated for both.
The Python Example in the Developer Information now supports Iron Python. The programming instructions are sometimes different since the ctypes module works differently. The example script documents the differences. If you use Python Tools for Visual Studio, it now installs in the Express editions (beginning with release 2.1). Node.js can also be installed in Visual Studio Express.
The executable in the Windows distribution package is now compiled with Visual Studio 2013 and will no longer work on XP. If you are using XP, Artistic Style will need to be recompiled on the XP machine.
A new Visual Studio Community Edition has been released. It is free, combines all of the Express editions into a single development environment, and allows the addition of Visual Studio extensions. There is an AStyle Extension available for installation. It has a graphic interface, adds menu entries, and can be used from within Visual Studio. To install it search the "Extensions and Updates", "Online" entry for "astyle".
Thanks to Peter A. Bigot, HyungKi Jeong, David Faure, and Carl Moore for their contributions.
With a new Artistic Style release some unchanged source files will be formatted because of changes to Artistic Style. You may want to format your source before making program changes in order to bring it up to date.
A new programming language, Objective‑C, has been added to Artistic Style. Four new options, "align‑method‑colon", "pad‑method‑colon=", "pad‑method‑prefix", and "unpad‑method‑prefix" have been added to format the methods. The options are described in a new "Objective‑C" section in the documentation. These new options affect only Objective‑C source code. They have no effect on the other programming languages.
Because of the longer continuation indents sometimes needed for Objective‑C, the option "max-instatement-indent" may need to be increased. If you are not getting the paren and block paren alignment you want, try increasing this value. The default minimum is 40 and the maximum is 120.
A new bracket style option, "style=google", has been added. It uses attached brackets and indents the class access modifiers one-half indent. A complete description of the Google style is available at the google‑styleguide website (https://code.google.com/p/google-styleguide/). The website has standards for several programming languages along with a python program to verify the style and an emacs script for using the style.
A new indent option "indent-modifiers" will indent class access modifiers (public, protected, or 'private) one-half indent. The rest of the class is not indented. It is described in the "Indentation Options" section of the documentation.
Four new bracket modify options, "attach-namespaces", "attach-classes", "attach-inlines", and "attach-extern-c", can be used to modify your selected bracket style. They are described in a new "Bracket Modify Options" section of the documentation.
A new option, "remove-brackets", will remove brackets from conditional statements. The statement must be a single statement on a single line. It is described in the "Formatting Options" section of the documentation.
A new option, "indent-preproc-cond", will indent preprocessor conditional statements (#if #elif, #else, #endif). It is described in the "Indentation Options" section of the documentation. The option "indent-preprocessor" has been deprecated and will be removed in a future release. Use "indent-preproc-define" instead. The processing of preprocessor #define statements has not changed.
A new option, "remove-comment-prefix", will remove a leading '*' from multi-line comments. It is described in the "Formatting Options" section of the documentation. With the syntax coloring of modern editors a leading '*' for comment lines is not as useful as it once was. The current trend is toward code that is easier to maintain. The idea is that a style that is hard to maintain will discourage modification and updating. The converted style should retain most of the formatting within the comment and result in a comment that is easier to maintain. For consistency the option also indents multi-line comments that are not preceded by the '*'. This may slightly modify the indentation of any commented-out code.
The option "pad-first-paren-out" was fixed to not pad if the following paren is empty. This makes the option consistent with "pad-paren-out". To fix empty parens that have been padded run with the option "unpad-paren" in addition to "pad-first-paren-out". This needs to be done only once.
Processing of C++11 raw string literals has been added.
The compiler definition ASTYLE_NO_VCX (no Visual Studio exports) has been changed to ASTYLE_NO_EXPORTS and can be used with any Windows compiler. The Clang compiler needs this option to avoid errors on dynamic libraries. It removes the "__declspec(dllexport)" definition from exported functions. Linux compilers do not use this.
A new shared object (DLL) entry point, AStyleMainUtf16, has been added for processing C# UTF-16 strings. C# does not have built in functions for converting the UTF-16 strings to UTF-8. This entry point will accept UTF-16 strings, format the source code, and return UTF-16 strings. The error handling function and version number still use UTF-8 strings. The C# example program in the "Developer Information" shows the new calling procedure. Changes from the previous release are marked in the example.
C# strings are UTF-16 on both Windows and Linux. C# does not use the UTF-32 wchar_t strings on Linux. Qt also uses UTF-16 on both Windows and Linux, but has built in UTF-8 conversion functions. Qt strings can be converted to UTF-8 by Qt, or the new entry point can be used. There may be other "managed code" applications on Linux that use UTF-16.
The "Links" page has two new sections for links mentioned in previous versions of Artistic Style. It links to free software and other information.
The "Developer Information" section has a new example and download for calling Artistic Style from an Objective‑C program. Since it is another "C" language the only thing needed is to link the program with a library build of Artistic Style. The example was developed on Windows and Linux using the GNUstep project. Since the example is a console program the problems with the GNUstep GUI have been avoided. It has not been tested on a Mac, but should be close to working. The "Developer Information" section also has a new page for "Objective‑C on Windows and Linux" which has information on compiling and running the example on those systems.
The executable included in the Windows distribution was compiled with Visual Studio 2010 (platform toolset v100). Higher releases contain dependencies on Windows API functions that exist only on Windows Vista, Windows 7, and Windows 8. This means that applications built with a Visual Studio 2012 C++ compiler would fail to load and execute on Windows XP.
If you are using Windows Vista or higher, and have a Visual Studio 2012 or higher compiler available, recompiling will probably result in faster execution. If you use a compiler other than Visual Studio, you can probably get better execution by compiling using the C++11 standards. Artistic Style uses a lot of string vectors and the new move semantics will probably result in faster execution.
Thanks to Evmenov Georgiy, Matthew Woehlke, Jiang, Ruzzz, and beta100100 for their contributions.
With a new Artistic Style release some unchanged source files will be formatted because of changes to Artistic Style. You may want to format your source before making program changes in order to bring it up to date.
A new option, "max-code-length=#" or "xC#", will limit the length of code on a line. A new option "break‑after‑logical", or "xL", will modify a line break for conditionals. See the documentation for details.
A new option, "pad-first-paren-out" or "xd", will pad only the first paren in a series on the outside. See the documentation for details.
A new option, "indent=force-tab-tab=#" or "xT#", will allow force tab indents with a tab length that is different than the indent length. See the documentation for details.
The short option for delete-empty-lines has changed from "xd" to "xe".
The C++11 standard for range-based "for" loops, "enum" with a base type, and rvalue references is now supported. The formatting of rvalue references is determined from the existing "align-pointer" and "align-reference" options.
Closing the ending angle brackets of templates is now allowed by the C++11 standard. A new option, "close-templates" or "xy", will close the whitespace in the angle brackets of template definitions. Be sure your compiler supports this before making the changes.
The C/C++ keyword 'extern "C"' in a preprocessor no longer causes an extra indent.
Formatting of C++/CLI managed pointers (the '^' character) has been added to the "align-pointer" option.
The breaking of switch "default" statements has been fixed. The "default" statements that have been incorrectly broken will be fixed in this release.
The byte order mark (BOM) has been removed from ASLocalizer.cpp for all platforms. The encoding of the file is UTF-8. Many Windows editors can now recognize UTF-8 encoding without the BOM. Visual Studio has an option that needs to be set. With others, such as CodeBlocks, identification is automatic. On Linux, UTF-8 is the default encoding.
Translations have been added for Dutch, Finnish, Italian, Japanese, Korean, Polish, Portuguese, Russian, Swedish, and Ukrainian. The translations were done with an automated translation program, Google Translate, so they may not be the best translation possible. The translations are at the end of ASLocalizer.cpp in the form of an English‑Translation pair. If you correct a translation, send the source as a bug report and it will be included in the next release. To add a language, see "Internationalization" in the "General Information" section of the documentation. Send the addition as a bug report and it will be included in the next release.
There is a new Linux makefile for the Clang Compiler. Clang is a free compiler can be installed as a package on many Linux distributions. Some of its features are fast compiles, low memory use, expressive diagnostic messages, and GCC compatibility. It includes a static analyzer tool that finds potential bugs in your source code. An experimental version can be installed on a Windows platform. There is more information in the Install Information documentation.
Visual Studio automatically creates an import library and an export file when you link a program that contains exports. It will do this for even a static library if it contains a __declspec(dllexport) definition. The Artistic Style library (ASTYLE_LIB) build contains such exports, which causes an import library and export file to be created when they may not be needed. A new preprocessor definition, ASTYLE_NO_VCX (no Visual Studio exports) can be declared to eliminate the files from the output. Use this only for static libraries or when the AStyle source is included in the compile. Do NOT use this when compiled as a shared (dynamic) library. It is effective only for Visual Studio 2012. It will NOT work with previous versions. It has no effect with other compilers since they require a separate option to create the import library and export files.
The executable included in the Windows distribution was compiled with Visual Studio 2010 (platform toolset v100). Visual Studio 2012 (platform toolset v110) contains dependencies on Windows API functions that exist only on Windows Vista, Windows 7, and Windows 8. This means that applications built with a Visual Studio 2012 C++ compiler would fail to load and execute on Windows XP. Artistic Style was therefore compiled with Visual Studio 2010 to work on computers using Windows XP.
If you are using Windows Vista or higher, and have the Visual Studio 2012 compiler available, recompiling with Visual Studio 2012 will probably result in faster execution. The Windows distribution has Visual Studio 2012 project files available.
If you use a compiler other than Visual Studio, you can probably get better execution by compiling using the C++11 standards. Artistic Style uses a lot of string vectors and the new move semantics will probably result in faster execution. (To use C++11 on GCC and MinGW use the option --std=c++0x). This may change on future compiler releases.
The "Developer Information" page has a new example and download for calling Artistic Style from a Python script. It will run with both Python 2 and Python 3. Using Python 3 shows an example of formatting a Unicode string with Artistic Style. Unicode strings must be encoded to UTF-8 before formatting and decoded back to Unicode afterward. The example script shows the technique for doing this. It also shows how to set up the function pointers and allocate memory in Python.
If you use Visual Studio on Windows, it can now be used for Python development. Python Tools for Visual Studio (PTVS) is a free and open source plug-in for Visual Studio 2010 that supports Python and Iron Python. Other interpreters such Jython can be added. It can be easily switched between Python versions or different interpreters. But the best thing is the Visual Studio debugging support using the .NET debugger and the normal Visual Studio debugger. It enables you to set break points, step through functions, change the current statement, inspect local variables, and perform other operations while debugging. It is best to use it with a project file, a minor irritation for single page scripts. And there are some minor bugs. But overall it works quite well.
Thanks to Christopher Sean Morrison, Keith OHara, louis6g, and J for their contributions.
Previous releases are available in the News Archives.