Code beautifier

Overview

Travis CI Travis CI AppVeyor Coverity Coverage Status


Uncrustify

A source code beautifier for C, C++, C#, ObjectiveC, D, Java, Pawn and VALA

Features

  • Highly configurable - 742 configurable options as of version 0.72.0
  • add/remove spaces
    • sp_before_sparen: Add or remove space before '(' of 'if', 'for', 'switch', 'while', etc.
    • sp_compare: Add or remove space around compare operator '<', '>', '==', etc
  • add/remove newlines
    • nl_if_brace: Add or remove newline between 'if' and '{'
    • nl_brace_while: Add or remove newline between '}' and 'while' of 'do' statement
  • add/remove blanklines
    • eat_blanks_before_close_brace: Whether to remove blank lines before '}'
    • nl_max: The maximum consecutive newlines (3 = 2 blank lines)
  • indent code
    • indent_switch_case: indent_switch_case: Spaces to indent 'case' from 'switch'
    • indent_class_colon: Whether to indent the stuff after a leading base class colon
  • align code
    • align_func_params: Align variable definitions in prototypes and functions
    • align_struct_init_span: The span for aligning struct initializer values (0=don't align)
  • modify code
    • mod_full_brace_for: Add or remove braces on single-line 'for' statement
    • mod_paren_on_return: Add or remove unnecessary paren on 'return' statement

Here is an example configuration file, and here is a before and after C source example. That should give you a pretty good idea of what Uncrustify can do.


Binaries

Pre compiled binaries for Windows can be downloaded here.

Build

Python is an "interpreted high-level programming language for general-purpose programming", for this project it is needed to extend the capabilities of CMake.

CMake is a tool that generates build systems (Makefiles, Visual Studio project files, Xcode project files and others).

To generate a build system for Uncrustify using CMake, create a build folder and run CMake from it:

$ mkdir build
$ cd build
$ cmake ..

(Use cmake -G Xcode .. for Xcode)

Then use the build tools of your build system (in many cases this will simply be make, but on Windows it could be MSBuild or Visual Studio). Or use CMake to invoke it:

$ cmake --build .

If testing is enabled, CMake generates a test target, which you can build using your build system tools (usually make test). This can also be invoked using CTest:

$ ctest -V -C Debug

There is also an install target, which can be used to install the Uncrustify executable (typically make install).

A note on CMake configurations

Some build systems are single-configuration, which means you specify the build type when running CMake (by setting the CMAKE_BUILD_TYPE variable), and the generated files then build that configuration.

An example of a single-configuration build system are Makefiles. You can build the Release configuration of Uncrustify (from the build folder) with:

$ cmake -DCMAKE_BUILD_TYPE=Release ..
$ make

Other build systems are multi-configuration, which means you specify the build type when building.

An example of a multi-configuration build system are Visual Studios project files. When you open the project in Visual Studio, you can select which configuration to build. You can also do this while building from the command line with cmake --build . --config Release.

Bugs

Post any bugs to the issue tracker found on the projects GitHub page: https://github.com/uncrustify/uncrustify/issues

Please include the following with your issue:

  • a description of what is not working right
  • input code sufficient to demonstrate the issue
  • expected output code
  • configuration options used to generate the output

More about this is in the ISSUE_TEMPLATE

Known problems

Look at the Wiki

Which repositories have uncrustify?

Look here

Contribute

If you want to add a feature, fix a bug, or implement missing functionality, feel free to do so! Patches are welcome! Here are some areas that need attention:

  • Patches for Objective-C support. We really need someone who knows this language as it has more than plenty open issues. A good starting point would be to integrate changes made in the Unity fork
  • Test Java support and provide feedback (or patches!)
  • Test Embedded SQL to see what works
  • A logo of some sort
  • Anything else that you want to do to make it better?

A note about pull requests

Firstly take a look at the CONTRIBUTING.md

Currently we have two continuous integration systems that test your PRs, TravisCI and Appveyor. Tested are the test cases, the formatting of the code base and the output of the command line options.

Test cases can be found in the tests/ directory. Every file ending with .test is a test set. Inside each line with these components is a single test: testNr[!] testConfigFileName testInputFileName [lang]

The configuration file testConfigFileName has to be located inside tests/config, the input file testInputFileName inside tests/input/<testSetName>/, and expected results file inside the tests/expected/<testSetName>/ directory. Expected results have the following naming convention: testNr-testInputFileName.

Optionally a ! can follow the testNr to enable a custom rerun configuration. Rerun configurations need to be named like this: testConfigFileName(without extension)+.rerun+.extension

Also, optionally a language for the input can be provided with lang.

The codebase has to be formatted by the options set up in forUncrustifySources.cfg. Failing to format the sources correctly will cause TravisCI build failures.

The Command line interface (CLI) output is tested by the test_cli_options.sh script. It is located inside of tests/cli/ and operates on the subdirectories of that folder.

If a PR is altering the CLI output, files inside those directories might need to be manually updated. This often happens when options are added, removed or altered. Keep in mind that the version string line (example: # Uncrustify-0.69.0_f) of outputs from commands like --show-config should be replaced with a blank line.

Debugging

The first method is to use uncrustify itself to get debug informations. Using:

   uncrustify -c myExample.cfg -f myExample.cpp -p myExample.p -L A 2>myExample.A

you get two files for the first informations. The p-file gives you details of the parsing process and indentation.

# Line                Tag              Parent          Columns Br/Lvl/pp     Flag   Nl  Text
#   1>              CLASS[               NONE][  1/  1/  6/  0][0/0/0][  10070000][0-0] class
#   1>               TYPE[              CLASS][  7/  7/ 14/  1][0/0/0][  10000000][0-0]       Capteur
#   1>         BRACE_OPEN[              CLASS][ 15/ 15/ 16/  1][0/0/0][ 100000400][0-0]               {

The A-file gives you many details about the run itself, where the process is running thru, which values have the most important variables.

tokenize(2351): orig_line is 1, orig_col is 1, text() 'class', type is CLASS, orig_col_end is 6
tokenize(2351): orig_line is 1, orig_col is 7, text() 'Capteur', type is WORD, orig_col_end is 14
tokenize(2351): orig_line is 1, orig_col is 15, text() '{', type is BRACE_OPEN, orig_col_end is 16

It might be usefull to add some code lines to see where something is happening. Use the package unc_tools. Remove the comment at line:

#define DEVELOP_ONLY

Import the package:

#include "unc_tools.h"

Add at some places the line:

prot_the_line(__LINE__, 6, 0);

Compile again with DEBUG option.

How to add an option

If you need a new option, there are a few steps to follow. Take as example the option sp_trailing_ret_t

First define the option:

  • Insert the code below to the file src/options.h _NOTE: This file is processed by make_options.py, and must conform to a particular format. Option groups are marked by '//begin ' (in upper case; this example is lower case to prevent being considered a region marker for code folding) followed by the group description. Options consist of two lines of declaration preceded by one or more lines of C++ comments. The comments form the option description and are taken verbatim, aside from stripping the leading '// '. Only comments immediately preceding an option declaration, with no blank lines, are taken as part of the description, so a blank line may be used to separate notations from a description. An option declaration is 'extern TYPE\nNAME;', optionally followed by ' // = VALUE' if the option has a default value that is different from the default-constructed value type of the option. The 'VALUE' must be valid C++ code, and is taken verbatim as an argument when creating the option's instantiation. Note also that the line break, as shown, is required. _
// Add or remove space around trailing return operator '->'.
extern Option<iarf_e>
sp_trailing_ret_t;
  • Insert the code below to the file src/space.cpp
   if (chunk_is_token(first, CT_TRAILING_RET_T))
   {
      // Add or remove space around trailing return operator '->'.
      log_rule("sp_trailing_ret_t");
      return(options::sp_trailing_ret_t());
   }

Portability

We are pretty sure that nothing OS-specific is used in the code base. The software has been previously tested on the following operating systems:

  • Linux
  • QNX
  • OS X
  • FreeBSD, NetBSD, OpenBSD
  • Sun Solaris 9
  • Windows (binary available)

Running the program

NOTE This application works reasonably well but it has bugs. Do not apply it on your whole codebase without checking the results!

Here are ways to run it:

$ uncrustify -c mystyle.cfg -f somefile.c -o somefile.c.unc
$ uncrustify -c mystyle.cfg -f somefile.c > somefile.c.unc
$ uncrustify -c mystyle.cfg somefile.c
$ uncrustify -c mystyle.cfg --no-backup somefile.c
$ uncrustify -c mystyle.cfg *.c
$ uncrustify -c mystyle.cfg --no-backup *.c

The -c flag selects the configuration file. The -f flag specifies the input file. The -o flag specifies the output file. If flag -f is used without flag -o the output will be send to stdout.

Alternatively multiple or single files that should be processed can be specified at the command end without flags. If the flag --no-backup is missing, every file is saved with the initial name and an additional suffix (can be changed with --suffix).

For more options descriptions call:

$ uncrustify -h

Configuring the program

Uncrustify usually reads configuration files that are passed via the -c flag. If the flag is not provided Uncrustify will try to find a configuration file via the UNCRUSTIFY_CONFIG environment variable or a file with the name .uncrustify.cfg or uncrustify.cfg in your home folder.

To get a list of:

  • all available options use:

    uncrustify --show-config
  • all available options in a usable configuration file format use:

    uncrustify --update-config

    or

    uncrustify --update-config-with-doc

    As the names suggest both options can produce output that adds newly introduced options to your old configuration file. For this your old configuration file has to be passed via the -c flag:

    uncrustify --update-config-with-doc -c path/to/your.cfg

Example configuration files that can be used as a starting point can be found in the etc/ directory (such as ben.cfg).

Modify to your liking. Use a quality side-by-side diff tool to determine if the program did what you wanted. Repeat until your style is refined.

To ease the process a bit, some 3rd party tools are available:

  • Universal Indent GUI - A cross-platform graphical configuration file editor for many code beautifiers, including Uncrustify.
  • uncrustify_config - A web configuration tool based on Uncrustify's emscripten interface.
  • UncrustifyX - Uncrustify utility and documentation browser for Mac OS X

Under Windows: Uncrustify is a command-line tool, if you run it by double-clicking the executable, it will open a command prompt run the executable (which prints the help message), and then immediately close the window as uncrustify exits.

You can open the command prompt (which is an interactive terminal window that allows you to run commands without it closing as soon as they exit) and run uncrustify.exe there.

Issues
  • CMake build issues

    CMake build issues

    @jibsen I've just tested cmake build on windows and apparently it works but:

    • [x] there are no instructions on how to build with cmake
    • [x] cmake fails when it tries to create a /Testing directory because there is another file with the same name /TESTING
    • [x] seems like process is rather messy. It creates everything in the root and pollutes the repository with untracked files.
    • [x] modify appveyor.yml and .travis.yml to switch to cmake
    • [x] Add appveyor build status badge in README.md
    • [x] add helper script for running tests
    • [x] make_version.py is not working
    • [x] repository has to be cleaned of old build system files (gnu automake, mingw32 scripts, VS and Xcode solution files)
    Engineering 
    opened by mihaipopescu 63
  • Modernize options

    Modernize options

    This overhauls how we store and manage options, adding convenience and type safety, and especially, getting us down to one place where options and such are defined. The general idea here is that, rather than a great big list of options in a global struct, each individual option is a separate object with a static initializer to set up its information, including its default value. (For the sake of config handling, there will still likely be a giant register_options sort of thing, but it will be generated by a script.) The benefits of this vs. the current approach are:

    • Options are much more readable. Options are now described fully in options.h, which (not by accident!) is not dissimilar to the output of --update-config-with-doc.

    • Options are type safe and can be accessed directly. It is impossible to use the wrong union member to access an option's value, because there is no more union. The only place a map is needed is for dealing with the config file (reading/updating/documenting). While #1945 already achieves this to an extent, it added two more places where options needed to be defined... see next item.

    • Options are defined in exactly one place. Defaults are defined along with the option definition. (This is sort of a lie, but as far as what code developers would ever touch, it is true. The rest is auto-generated.) The (debug) logic to enforce ordering consistency can go away.

    • The logic to parse options from the config or convert them back to strings is be more localized and less monolithic.

    Old option declarations existed in as many as five places; the enum value in options.h, the registration (with string literals) in options.cpp, and (in some cases) setting the default value in a different location in options.cpp. #1945 added two more places; the accessor declaration and definition.

    The new declaration looks like:

    // This is an example option. Here is its description.
    // The description can be multiple lines. Line breaks are preserved as-is.
    extern option<bool>
    sp_example; // = true
    

    The script that generates options.cpp recognizes the optional // = X comment as specifying a default value (X is a C++ expression). The group markers should be obvious, and have the benefit of (by katepart, at least) being recognized region markers.

    We still have "accessors" (recall, the whole point of #1945 was to introduce an alternate mechanism for accessing option values that was source-compatible with what we introduce here), but the "accessor" is calling operator() on the static option instance. This no longer returns a reference; assignment is instead done directly (sp_foo = val vs. sp_foo() = val). Additionally, places that take options (e.g. blank_line_set) can now take the option object and retrieve the option name from the same, eliminating the need for macros to pass both the name and accessor.

    I think this will also encourage writing better documentation, since the descriptions aren't burdened with indenting, quoting (or escaping), or being highlighted as string literals, and it is less awkward to write multi-line descriptions. (Also, one of the things I'm doing in this PR is thoroughly revising all of the option descriptions for consistency of phrasing and, for options that needed it, clarity.)

    Here's a comparison of using an option:

    // Old
    if (cpd.settings[UO_sp_example].a == AV_REMOVE)
    
    // New
    if (options::sp_example() == IARF_REMOVE)
    

    (This last part is already mostly achieved by #1945 and #1974, which were done largely in order to push most of the churn out of this PR. However, there are a few instances that #1974 skipped that are now ported, especially in newline.cpp.)

    Internals 
    opened by mwoehlke-kitware 40
  • Refactor tests

    Refactor tests

    This overhauls the test framework in order to consolidate run_tests.py with the CTest tests, as per my comments in #977. Said framework has "blossomed" into a multi-file module from a single script, but the code should be a little more readable, and some things (e.g. the color output) should work better. Most importantly, there is now virtually no difference between running the tests via CTest and running run_tests.py by hand. (This also means that #1820 is required to not break the CI, because that test is now being run by CTest also... which in turn means that this supersedes #1807.)

    Highlights:

    • The logic for actually running a test has been moved to a new Test class. This also incorporates the logic for parsing a test from the .test files, and acts as a container for all of the information needed to run the test (i.e. the various files used).
    • run_test.cmake has been replaced by run_test.py, which is a lightweight wrapper to set up and run a Test.
    • run_tests.py learned to generate the CTest script that sets up all of the test for CTest. Thus, running tests via CMake now looks like:
      • Run run_tests.py (at build time, not at configure time) to read the .test files and set up a list of Tests.
      • Ask each Test to write an add_test that will recreate that Test.
      • Run run_test.py (for each CTest test) with the necessary arguments to reconstruct the Test.
      • Execute the Test.
    • run_tests.py thus gets to stick around, with a 'run by hand' mode that basically cuts out the middle two steps of the above.

    I did choose to go with what CTest was doing where it and the old run_tests.py disagree about how to run the "stability" tests in the case of separate .rerun files. While I'm not convinced that that discussion (from https://github.com/uncrustify/uncrustify/pull/1799#discussion_r195225473) is resolved, the more I think about it, the more I'm inclined to believe that the CTest behavior (using the rerun_expected file as the input to the re-run pass, rather than the expected file) is the correct behavior. The existence of a separate .rerun file implies that it is known and expected that the first-pass output is not stable... although the existence of these cases in the first place seems worrisome. At any rate, there are no "unstable" tests with this approach.

    One down-side is that specifying the location of the uncrustify executable (for running run_tests.py by hand) is now required. This is probably avoidable, but at least initially, I punted, as the existing logic didn't seem like it would ever work for a CMake build.

    I also ruthlessly changed all instances of "output" to "expected"... including the source tree folder (hence the rather annoying diff; sorry about that!). I'm happy to back this out if it isn't wanted after all, but my impression from earlier PR's was that it will reduce confusion and was desired.

    This fixes #977 (or at least, I'm claiming that it does :slightly_smiling_face:):

    • .test parser regex doesn't support tabs (#854 (comment))
      • Parsing is back to being done exclusively in Python, so this is no longer an issue.
    • ability to iterate on .test files (add/remove tests) without regenerating the cache (see #972)
      • Generation of the CTest test script is now done at build time. Changes to the .test files require a rebuild to be picked up, but do not require a reconfigure.
    • ability to run a specified suite (can be outside of the default batch of suites) (see #976)
      • This can be done using run_tests.py (which is not going to go away; most of its logic is shared with running the tests via CTest). I'm not sure that it would make sense, but we could, as a follow-up to this PR, add the ability to specify additional .test files at configure time. The thing is, I'm not sure it makes sense to do this with CTest...
    • ability to show diffs on failures (-d option)
      • This was previously implemented by #1799. Although this does also effectively obviate that PR, diff output from CTest is still present.
    • ability to generate debug logs/files (-g option)
      • CTest simply doesn't offer the ability to make these sorts of changes without changing the tests. That said, a) this is still available via run_tests.py, and b) I wonder if for CTest there is actually any particular reason not to just make this always enabled? (If so, with this PR, that is a trivial change. It would even be possible, though somewhat more work, to add a configure option whether or not CTest tests should use -g.)
    • ability to use another result folder (--results option, useful when comparing result of two builds)
      • Again, specifying this when invoking CTest is not really practical. However, the CTest tests now write their output to the build directory, which should largely obviate the need for this change.

    This also conflicts with #1796, #1819, and indeed, any PR that adds tests. I'll rebase as necessary depending on what lands first. (#1820 should also land before this.)

    opened by mwoehlke-kitware 36
  • long method and variable declarations not correctly indented

    long method and variable declarations not correctly indented

    hi Ben,

    The fix for 536 solves the problem for the class declarations.

    Long method and variable declarations though are still not being indented correctly. They work normally, but in case of templatized parameters they break. Adding an additional check should handle this problem. Around line 1430 in indent.cpp we have this condition check. We need to add this additional check. See comment alongside the new condition.

    else if ((vardefcol > 0) && (pc->level == pc->brace_level) && ((pc->type == CT_WORD) || (pc->type == CT_FUNC_CTOR_VAR)) && (prev != NULL) && ((prev->type == CT_COMMA) || (prev->type == CT_TYPE) || (cpd.lang_flags & LANG_JAVA && prev->parent_type == CT_TEMPLATE) || // New condition added (prev->type == CT_WORD)) && ((pc->flags & PCF_VAR_DEF) != 0)) { LOG_FMT(LINDENT, "%s: %d] Vardefcol => %d\n", func, pc->orig_line, vardefcol); reindent_line(pc, vardefcol); }

    For the long method problem though, I am afraid I don't have a solution.

    Reported by: kaiser101

    Original Ticket: uncrustify/bugs/555

    Java 
    opened by gmaurel 35
  • Fixes that are needed to build on windows.

    Fixes that are needed to build on windows.

    In file: "compat_win32.cpp", need to change text() back to str.c_str(). (Refer to https://github.com/uncrustify/uncrustify/commit/9a8ad0599e4bfa7310ce4b7d9169b9c099f052a6). It breaks building on windows. This particular usage of c_str() is not related to parsing or chunking text.

    If the VisualC solution is being maintained, need to add "options_for_QT.cpp" and "options_for_QT.h" to the project file.

    With these changes, it builds with MSVS 2015.

    Engineering 
    opened by meldavis 30
  • Indent is wrong for Objective-C blocks inside function calls

    Indent is wrong for Objective-C blocks inside function calls

    + (void)pluginDidLoad:(NSBundle *)plugin
    {
        static dispatch_once_t onceToken;
    
        dispatch_once(&onceToken, ^{
                kSharedPlugin = [[self alloc] init];
            });
    }
    

    should be:

    + (void)pluginDidLoad:(NSBundle *)plugin
    {
        static dispatch_once_t onceToken;
    
        dispatch_once(&onceToken, ^{
              kSharedPlugin = [[self alloc] init];
        });
    }
    
    Objective C waiting_for_answer 
    opened by tonyarnold 29
  • split prototypes.h into individual header files

    split prototypes.h into individual header files

    This commit

    • splits the header prototypes.h in several files that correspond to their respective *.cpp source file
    • moves function comments to the header
    • adds a new directory named "include"

    I did not move the header files into the include directory yet, as this might break the build scripts. Could somebody please add the include directory to the compiler's/linker's include list. The header files can then be moved without trouble.

    Implements #868

    Engineering 
    opened by stefan-nu 27
  • Swift support

    Swift support

    Hello,

    First I would like to say that I love uncrustify! Been using it for around a year and I cannot live without it anymore.

    Now I would like to know what is the plan for the swift support. Is uncrustify going to support it? Is it work in progress? Or what is the state?

    Thanks :)

    FeatureRequest 
    opened by ajimix 26
  • Sorting order of usings

    Sorting order of usings

    Expected behaviour with mod_sort_using=true:

    using System;
    
    using System.Collections.Generic;
    

    Actual behaviour with mod_sort_using=true:

    using System.Collections.Generic;
    
    using System;
    

    So, sorting direction option required at config for proper behaviour of sorting process.

    uncrustify version: 0.64.

    C# 
    opened by Leopotam 26
  • Adding extra indentation in Apex code

    Adding extra indentation in Apex code

    The results of beautification are not what I expect.

    This is what the code looked like before:

    @isTest
    private class MyTestClass {
    @testSetup
    static void createCommonData(){
    (tab)Account a = newAccount();
    (tab)insert a;
    

    The beautified code should have looked like this:

    @isTest
    private class MyTestClass {
    (tab)@testSetup
    (tab)static void createCommonData(){
    (tab)(tab)Account a = newAccount();
    (tab)(tab)insert a;
    

    Actual Output

    The beautified code actually looked like this:

    @isTest
    private class MyTestClass {
    (tab)(tab)@testSetup
    (tab)(tab)static void createCommonData(){
    (tab)(tab)(tab)(tab)Account a = newAccount();
    (tab)(tab)(tab)(tab)insert a;
    

    Steps to Reproduce

    Add code to Atom editor Run command Atom Beautify: Beautify Editor This beautified code does not look right! Debug

    Here is a link to the debug.md Gist: https://gist.github.com/anonymous/f1b5b9139d6337b588e53b83bb9945e5

    (https://github.com/Glavin001/atom-beautify/issues/1361)

    FeatureRequest waiting_for_answer 
    opened by fricco 25
  • A few fixes in cpp parsing and formatting in some corner cases.

    A few fixes in cpp parsing and formatting in some corner cases.

    I've started using Uncrustify and found a few issues in my codebase which I hopefully have properly fixed. The original test are passing, and I've only extended the test cases adding new ones that fail without the fixes.

    Here is the current list of the fixes:

    • Fixes '&' reference seen as 'BYREF' in 'ARITH' context.
    • Fixes lambda wrongly indented if called and not assigned to anything.
    • Fixes ')' wrongly indented when 'noexcept' part of the signature.
    • Fixes '&' reference seen as 'ARITH' in trailing return 'BYREF' context.
    opened by Dandielo 2
  • Handling of CT_ASSIGN_DEFAULT_ARG with align_assign_span and align_assign_decl_func

    Handling of CT_ASSIGN_DEFAULT_ARG with align_assign_span and align_assign_decl_func

    Version: Uncrustify-0.74.0-2-e6b16b2d

    I am starting with the default configuration and this input:

    class CreationDialog : public QDialog
    {
      public:
        // These assignments (CT_ASSIGN_DEFAULT_ARG) should not be aligned...
        CreationDialog( QWidget *parent = 0, QString title = "", double doSpacing = 1.,
          QStringList names = QStringList() << "",
          QStringList processedFiles = QStringList() << "", bool BatchMode = false );
    
        void setFoo( double unit, const QString &unitString )
        {
          // ...but these (CT_ASSIGN) should
          m_unit = unit;
          m_unitString = unitString.simplified();
        }
    };
    

    Setting align_assign_span=1 leads to this:

    class CreationDialog : public QDialog
    {
    public:
    // These assignments (CT_ASSIGN_DEFAULT_ARG) should not be aligned...
    CreationDialog( QWidget *parent            = 0, QString title = "", double doSpacing = 1.,
                    QStringList names          = QStringList() << "",
                    QStringList processedFiles = QStringList() << "", bool BatchMode = false );
    
    void setFoo( double unit, const QString &unitString )
    {
    	// ...but these (CT_ASSIGN) should
    	m_unit       = unit;
    	m_unitString = unitString.simplified();
    }
    };
    

    Adding align_assign_decl_func=2 changes the output to

    class CreationDialog : public QDialog
    {
    public:
    // These assignments (CT_ASSIGN_DEFAULT_ARG) should not be aligned...
    CreationDialog( QWidget *parent = 0, QString title = "", double doSpacing = 1.,
                    QStringList names = QStringList() << "",
                    QStringList processedFiles = QStringList() << "", bool BatchMode = false );
    
    void setFoo( double unit, const QString &unitString )
    {
    	// ...but these (CT_ASSIGN) should
    	m_unit       = unit;
    	m_unitString = unitString.simplified();
    }
    };
    

    It seems that align_assign_decl_func not only matches CT_ASSIGN_FUNC_PROTO, but also CT_ASSIGN_DEFAULT_ARG.

    What I would like to have is to align "standard" assignments (CT_ASSIGN) and - ideally - function prototypes (CT_ASSIGN_FUNC_PROTO), but definitely not default arguments (CT_ASSIGN_DEFAULT_ARG). Is there an option to achieve this?

    C and C++11 
    opened by rwiesenfarth 0
  • sp_ptr_star_func_var doesn't work in typedefs

    sp_ptr_star_func_var doesn't work in typedefs

    Config file:

    sp_ptr_star_func_var = remove
    sp_after_ptr_star = force
    

    Test code:

    int (*    func)(void);
    typedef int (*    func_t)(void);
    

    Expected result:

    int (*func)(void);
    typedef int (*func_t)(void);
    

    Actual result:

    int (*func)(void);
    typedef int (* func_t)(void);
    
    C and C++11 
    opened by alexhenrie 0
  • Missing versions in spack

    Missing versions in spack

    I recently moved all my package management on my Mac from brew to spack and realised that the spack repos are not well maintained.

    Therefore I added the most recent versions and a patch for v0.73in spack/spack#27621.

    However if the developers of uncrustify don't want it to be published in spack let me know.

    opened by briederer 3
  • Including GLib macro breaks header file indentation

    Including GLib macro breaks header file indentation

    I noticed that declaring GLib derived classes using the G_DECLARE_FINAL_TYPE macro in C header files at least sometimes breaks proper indentation. See the attached minimal sample uncrustify-issue.zip: calling uncrustify -c uncrustify.cfg --replace --no-backup sample-ok.h on the header file where the aforementioned macro is commented out produces a properly formatted function prototype (according to the config; note: tab width is 4!) output, whilst the same call for sample-bad.h, where the macro is “active”, produces wrong output. The effect is reproducible with uncrustify ver. 0.69.0 (package on Ubuntu 20.04 LTS), 0.72.0 (package on Debian Bullseye), and a self-compiled 0.73.0. Any idea how I could fix this issue?

    C and C++11 
    opened by albrechtd 4
  • Parse error on trival, valid C source code

    Parse error on trival, valid C source code

    $ cat p.c int f (void) { _Pragma("P2");}

    $ gcc -c p.c $ cat p.cfg newlines = auto $ uncrustify -c p.cfg p.c Output suffix: .uncrustify Parsing: p.c as language C indent_text(4060): size is 2 indent_text(4062): File: p.c, open_line is 2, parent is NONE: Unmatched BRACE_OPEN indent_text(4060): size is 2 indent_text(4062): File: p.c, open_line is 2, parent is NONE: Unmatched BRACE_OPEN 1|$ uncrustify --version Uncrustify_d-86eb8205 $

    C and C++11 
    opened by RobertoBagnara 4
  • recalculate the level after #endif

    recalculate the level after #endif

    fixes #3336

    opened by guy-maurel 5
  • Space is always removed after cast to Map

    Space is always removed after cast to Map

    version: 0.73.0_f

    The space between ')' and 'JSON' variable is always removed and this cannot be controlled if the casting is defined using angles.

    String responseBody = res.getBody(); Map<String,Object> jsonResponse = (Map<String,Object>) JSON.deserializeUntyped(responseBody);

    Please fix this to be controlled somehow.

    opened by jaguraphg 5
  • Parse error: indent_text(4060), indent_text(4062)

    Parse error: indent_text(4060), indent_text(4062)

    The test case comes from https://slixe.de/stash/projects/MAS/repos/libfirm/browse/ir/be/test/compress95.c?at=3232017bf40a3784cf75fc5a17bad8c0d545075b compress95.c.gz

    $ cat p.cfg code_width = 80 $ uncrustify compress95.c -c p.cfg Output suffix: .uncrustify Parsing: compress95.c as language C indent_text(4060): size is 3 indent_text(4062): File: compress95.c, open_line is 1285, parent is NONE: Unmatched BRACE_OPEN indent_text(4060): size is 3 indent_text(4062): File: compress95.c, open_line is 1299, parent is NONE: Unmatched BRACE_OPEN indent_text(4060): size is 3 indent_text(4062): File: compress95.c, open_line is 1285, parent is NONE: Unmatched BRACE_OPEN indent_text(4060): size is 3 indent_text(4062): File: compress95.c, open_line is 1299, parent is NONE: Unmatched BRACE_OPEN indent_text(4060): size is 3 indent_text(4062): File: compress95.c, open_line is 1285, parent is NONE: Unmatched BRACE_OPEN indent_text(4060): size is 3 indent_text(4062): File: compress95.c, open_line is 1299, parent is NONE: Unmatched BRACE_OPEN $ uncrustify --version Uncrustify_d-0.73.0-220-27a3bd91

    opened by RobertoBagnara 1
  • Uncrustify gives parse error on valid C code

    Uncrustify gives parse error on valid C code

    Current Git HEAD revision gives a parse error on valid C code. Operating system is Ubuntu 20.04.

    $ cat r.c
    #define EXECUTE(x, CODE)                             \
      do {                                               \
        int i = (x);                                     \
        CODE;                                            \
      } while (0)
    
    extern void bar(int i);
    
    void foo(int v) {
      EXECUTE(v,
        do {
          bar(i);
        }
        while (0));
    }
    $ gcc -c r.c
    $ cat r.cfg
    code_width                      = 80
    $ ./uncrustify -c r.cfg -f r.c -o s.c
    Parsing: r.c as language C
    parse_cleanup(506): pc->orig_line is 14, orig_col is 14, text() is ')', type is PAREN_CLOSE
    parse_cleanup(512): (frm.top().type + 1) is SWITCH
    parse_cleanup(525): File: r.c, orig_line is 14, orig_col is 14, Error: Unexpected ')' for 'DO', which was on line 11
    $ ./uncrustify -v
    Uncrustify_d-0.73.0-210-89d022f5
    

    All files are contained in the attached archive.

    r.tar.gz

    C and C++11 
    opened by RobertoBagnara 1
Git Source Code Mirror - This is a publish-only repository and all pull requests are ignored. Please follow Documentation/SubmittingPatches procedure for any of your improvements.

Git - fast, scalable, distributed revision control system Git is a fast, scalable, distributed revision control system with an unusually rich command

Git 40.3k Nov 30, 2021
Visual Studio Code

Visual Studio Code - Open Source ("Code - OSS") The Repository This repository ("Code - OSS") is where we (Microsoft) develop the Visual Studio Code p

Microsoft 124.7k Nov 30, 2021
Sharetribe Go is a source available marketplace software, also available as a hosted, no-code SaaS product. For a headless, API-first marketplace solution, check out Sharetribe Flex: https://www.sharetribe.com/flex.

Sharetribe Sharetribe develops advanced marketplace software for every business life cycle stage. Sharetribe Go gives you the complete feature set to

Sharetribe 2.2k Nov 23, 2021
Backdrop core code repository.

Backdrop is a full-featured content management system that allows non-technical users to manage a wide variety of content. It can be used to create al

Backdrop CMS 806 Nov 27, 2021
Low-code programming for event-driven applications

Node-RED http://nodered.org Low-code programming for event-driven applications. Quick Start Check out http://nodered.org/docs/getting-started/ for ful

null 13.4k Nov 21, 2021
Free and open fair-code licensed node based Workflow Automation Tool. Easily automate tasks across different services.

n8n - Workflow Automation Tool n8n is an extendable workflow automation tool. With a fair-code distribution model, n8n will always have visible source

n8n - Workflow Automation 19k Nov 29, 2021
Accelerated Text is a no-code natural language generation platform. It will help you construct document plans which define how your data is converted to textual descriptions varying in wording and structure.

A picture is worth a thousand words. Or is it? Tables, charts, pictures are all useful in understanding our data but often we need a description – a s

TokenMill 394 Nov 30, 2021
⏰ A low-code queue management system ⏰

ZeroQueue ⏰ A low-code queue management system ⏰ Powered by BullMQ - the fastest, most reliable, Redis-based queue for Node. Installation • Usage • Co

ZeroQueue 95 Nov 14, 2021
historical code from reddit.com

This repository is archived. This repository is archived and will not receive any updates or accept issues or pull requests. To report bugs in reddit.

The Reddit Archives 15.9k Nov 30, 2021
Thoughts, Ideas and bits of code for SMF (2.1)

SMF This is a SMF 2.1 development repository. The software is licensed under BSD 3-clause license. Contributions to documentation are licensed under C

Simple Machines 442 Nov 30, 2021
OpenStack Storage (Swift). Mirror of code maintained at opendev.org.

OpenStack Swift OpenStack Swift is a distributed object storage system designed to scale from a single machine to thousands of servers. Swift is optim

Mirrors of opendev.org/openstack 2.3k Nov 25, 2021
Self-hosted file/code/media sharing website. ~~~~~~~~~~~~~~~~~~~ Demo: https://demo.linx-server.net/

Development on this repository has been frozen. Feel free to send a pull request if you are maintaining an active fork of this project to add a link t

Andrei Marcu 1.2k Nov 30, 2021
Corteza 3.7 9.3 Go CRM including a unified workspace, enterprise messaging and a low code environment for rapidly and securely delivering records-based management solutions.

What is Corteza? Corteza brings your user ecosystem and essential applications together on one platform, unifying them via CRM, Advanced Identity and

Corteza Project 345 Nov 25, 2021
Low-code programming for event-driven applications

Node-RED http://nodered.org Low-code programming for event-driven applications. Quick Start Check out http://nodered.org/docs/getting-started/ for ful

null 13.5k Nov 29, 2021
map.geo.admin.ch source code

mf-geoadmin3 Freezed version map.geo.admin.ch mf-geoadmin-3 will not be developed further (bug fix only). map.geo.admin.ch will only be developed in t

geo.admin.ch 215 Nov 23, 2021
👨‍💻 Code snippets for teams and individuals.

Snipt Running locally Clone the repo. cd snipt python3 -m venv ~/.virtualenvs/snipt source ~/.virtualenvs/snipt/bin/activate pip install -r requiremen

Nick Sergeant 59 Nov 20, 2021
Pasty is a fast and lightweight code pasting server

pasty Pasty is a fast and lightweight code pasting server General environment variables Environment Variable Default Value Type Description PASTY_WEB_

Lukas Schulte Pelkum 75 Nov 19, 2021
Source Code

/** * Coppermine Photo Gallery * * v1.0 originally written by Gregory Demar * * @copyright Copyright (c) 2003-2020 Coppermine Dev Team * @licen

Coppermine Photo Gallery 49 Nov 30, 2021
A self-hosted server for source code parsing

bblfshd This repository contains bblfsh daemon (bblfshd), which includes the runtime that runs the driver in containers and the bblfshctl, a cli tool

Babelfish 317 Nov 26, 2021
VS Code in the browser

code-server · Run VS Code on any machine anywhere and access it in the browser. Highlights Code on any device with a consistent development environmen

Coder 50.1k Nov 27, 2021
Browser code editor awesomeness

ICEcoder Code editor awesomeness ...in your browser ICEcoder is a browser based code editor, which provides a modern approach to building websites. By

ICEcoder 1.3k Nov 20, 2021
🔥 The most advanced open-source online code execution system in the world.

Judge0 CE ?? The most advanced open-source online code execution system in the world. Table of Contents About Features Get Started Flavors Supported L

Judge0 847 Nov 25, 2021
Universal code search (self-hosted)

Sourcegraph OSS edition is a fast, open-source, fully-featured code search and navigation engine. Enterprise editions are available. Features Fast glo

Sourcegraph 5.4k Nov 26, 2021
Codeless or low-code User Experience test editing and management.

Uier Uier (UI[test]er) is a tool that provides codeless or low-code User Experience test editing and management. Uier uses Selenium to perform testing

Sjoerd van der Hoorn 104 Nov 20, 2021
The source code that powers readthedocs.org

Welcome to Read the Docs Purpose Read the Docs hosts documentation for the open source community. It supports Sphinx docs written with reStructuredTex

Read the Docs 6.8k Nov 20, 2021
Free and open fair-code licensed all-in-one growth marketing & management software

erxes is an open fair-code licensed all-in-one growth marketing & management software. We offer an all-in-one solution for sales, marketing, and custo

erxes Inc 2k Nov 30, 2021
📦 Build code for NextcloudPi: Raspberry Pi, Odroid, Rock64, Docker, curl installer...

English | Traditional Chinese 繁體中文 | Simplified Chinese 简体中文 NextCloudPi This is the build code for NextCloudPi. NextCloudPi is a ready to use image f

Nextcloud 1.5k Nov 19, 2021
Galette membership management web application towards non profit organizations main source code (mirror)

Galette Gestionnaire d'Adhérents en Ligne Extrêmement Tarabiscoté mais Tellement Efficace English Galette is a membership management web application t

Galette 30 Nov 29, 2021