Community
Participate
Working Groups
Build Identifier: I20100805-1700 The formatter likes to flow code into fewer lines and within the max line length. This can often leave some code less readable. In particular, long String concatenation for in-line templates get messed up. Consider a JUnit test which creates a YAML input stream String yaml = "invoice: 34843" + "date : 2001-01-23" + "bill-to: &id001" + " given : Chris" + " family : Dumars" + " address:" + " lines: |" + " 458 Walkman Dr." + " Suite #292" + " city : Royal Oak" + " state : MI" + " postal : 48046"; or array initialization Address addreses[] = new Address[] { new Address(123, "South Main", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), }; gets uglified rather than beautified by the formatter (100 columsn): String yaml = "invoice: 34843" + "date : 2001-01-23" + "bill-to: &id001" + " given : Chris" + " family : Dumars" + " address:" + " lines: |" + " 458 Walkman Dr." + " Suite #292" + " city : Royal Oak" + " state : MI" + " postal : 48046"; Address addreses[] = new Address[] { new Address(123, "South Main", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), }; One way to disable the flow/fill done by the formatter is to put // comments at the end of the line, but that's pretty ugly. (A key binding that did that automatically migh help, though, something like Ctlr=/ does for putting // at the beginning of the line) But these get in the way as well and clutter the code. There are formatter options for forcing array initializers to one item per line, and for binary expressions wrapping/indenting that can do this, but those are to aggressive and apply to all array initializers or all expressions, which distort code (or they may not apply to short examples that can flow onto one line, if the user has set that option). Instead, I propose a means to disable formatting, re-indentation, and code flow/filling for regions of text by detecting a comment marker at the beginning of a declaration, statement, expression or { } block to suppress formatting there: // NOFORMAT String yaml = "invoice: 34843" + "date : 2001-01-23" + "bill-to: &id001" + " given : Chris" + " family : Dumars" + " address:" + " lines: |" + " 458 Walkman Dr." + " Suite #292" + " city : Royal Oak" + " state : MI" + " postal : 48046"; I don't care too much about how this is expressed; this is just a suggestion. // @NOFORMAT or // @NoFormat or // @noformat are alternatives. It may work best in practice to allow the marker to be placed within a paren group or { } block and it applies until the end of the containing () or {}: init(new Address[] { // @noformat new Address(123, "South Main", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), }); rather than requiring the marker before the { : init(new Address[] // @noformat { new Address(123, "South Main", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), }); but this may not work well with all formatter settings for { placement. Another option would be an annotation such as @Formatter("disabled") but that is only good for declarations and would not apply to code like init(new Address[] { new Address(123, "South Main", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), new Address(4261, "Ash", "Anytown", 34567), }); so I think a special comment marker is needed instead of an annotation. Reproducible: Always Steps to Reproduce: See details
Since 3.6, the formatter accepts disabling/enabling tags? Which is, I guess, exactly what your are requesting for... Hence, you can set your disabling tag either to NOFORMAT, @NOFORMAT, @noformat, etc. in the Off/On Tags tab of your formatter profile... *** This bug has been marked as a duplicate of bug 27079 ***
Verified for 3.6.1 RC2 using build M20100825-0800.
Verified for 3.7M2 using build I20100909-1700