Make the language "less" newline sensitive

0.2 pending discussion with anders

Not sure if this is the right place for this comment, feel free to point me to a better Issue.

If this means I can add newline on long lines for readability this would be great!
I have two scenarios in particular:

Long if-statements, these can be hard to read. For example:

var value = myParam == 'value1' ? settingsTable.value1 : myParam == 'value2' ? settingsTable.value2 : {}

This would be much more readable over several lines:

var value = myParam == 'value1' ? settingsTable.value1 : 
            myParam == 'value2' ? settingsTable.value2 : 
            {}

Same thing goes for conditional deploys when they are implemented:

resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2020-03-01-preview' when (condition) = {

vs

resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2020-03-01-preview' 
when (condition) = {

Adding related issues:

Also adding #1760 as a related issue

I noticed a dirty hack to split functions over multiple lines, using block comments:

var multilineFunction = resourceGroup(/*
*/ mySubscription, /*
*/ myResourceGroup)

Same thing works for ternary, and probably generally for all expressions:

var test2 = thisIsAVeryLongTernary && iWouldLikeToSplitIt ?/*
*/ acrossMultiple :/*
*/ lines

I don't recommend anyone actually use this 😄

Can the team document these under limitations? Same as multiple line arrays?

masters3d (@masters3d)

masters3d (@masters3d) - We have a known limitations section in our README. Did you see this there? Where else would you want/expect to see this?

Tom FitzMacken (@tfitzmac) / Jonathan Gao (@mumian) FYI

Feedback from MVP summit asking if we should introduce more flexibility on our new line sensitivity:

Anthony Martin (@anthony-c-martin)

I will add a comment on this one. I don't want to stop other people having options for what they want and personal preference for code style or configuration management style.

One thing that I have come to appreciate over time when you have large configuration documents, having a single configuration item on each line, ensures that it's easier to maintain in version control and also helps to avoid merge conflicts.

I do appreciate how json formatter takes arrays and puts them on new lines by default, unless you minify the json. I didn't appreciate this at first, however auto format in a deterministic fashion (along with the linting rules) is extremely helpful for not committing errors.

often you do have a long list and it's tempting to put multiple items on a single line, however having the ability to autoformat is the most important thing for me. Otherwise after working on code or configurations you have added spaces or changes that are not actually configuration changes. The auto format cleans up the code and alignment, so you only check in actual changes, not just changes in how a document is 'manually' formatted.

To summarize: I am not against a new feature, however it would be my preference if having an auto format + linting, would be available as part of the implementation.

In saying this I am also guilty of the following, ... which Anthony Martin (@anthony-c-martin) mentioned further up in this issue #146 (comment)

        networkSecurityGroup: !(contains(sn, 'NSG') && bool(sn.NSG)) ? null : /*
        */ {
          id: contains(sn, 'NSGID') ? sn.NSGID : NSG[index].id
        }

Feedback from MVP summit asking if we should introduce more flexibility on our new line sensitivity:

And the feedback from today's community call with a demo of an MVP implementation

Link to demo: https://youtu.be/R6SyuRhTmmc?t=1145s

🤔🤔🤔

"With functions, we keep the command and can now split over multiple lines" ✅
- Really love this.
- Any chance we can do it without commas as well?
e.g.

var func = resourceGroup(
     mySub
     myRGName
)

I wrote this, just this week, so this feature would avoid the mess below

targetResourceId: ep.eptype != 'azure' ? null :  resourceId( EPs[index].subname, /* subscription
                                                             */ EPs[index].rgname, /*  resourcegroup
                                                             */ EPs[index].restype, /* resourcetype e.g. publicip
 resource name */ '${EPs[index].resnameprefix}${ep.prefix}-${EPs[index].org}-${EPs[index].app}-${EPs[index].env}-${ep.name}')

Array and Objects
- The trailing comma on the last item was confusing on the call, however now I realize I like it.
- I like not having to put the trailing comma
- I like being able to have the trailing comma, since I may comment out a line and it's frustrating cleaning up commas, when you are only just testing commenting something out.

e.g. I would expect below

	var arr = [
	    'abc',
	    'def'
	]

	var arr = [ 'abc', 'def' ]
	
	var arr = [
	    'abc',      //<--- this is nice to have, since i just temporarily commented 'def'
	    //'def'
	]

       var arr = [
         'abc'
         'def'         // updating comment to say that I will always be a fan of no commas here.
      ]

I think I like having the delimiter for single line, however it's only what I am familiar with.
I think I time I could grow to like the simplicity of doing spaces only, less characters to deal with.
- so long as it formats well, I am happy.

After rewatching the video, my brain caught up and I think all of this is good ✅ I didn't vote on the call, however I would say yes now.

Would trailing commas be permitted on function calls, as in:

resourceId(
  'Microsoft.Rp/widgets',
  'myWidget',
)

Not sure if any language other than Python permits that syntax, but it can help generate more useful diffs when adding or removing arguments.

Ben Wilkinson (@brwilkinson)

To summarize: I am not against a new feature, however it would be my preference if having an auto format + linting, would be available as part of the implementation.

Ben Wilkinson (@brwilkinson) I second that. Actually, I think it is a requirement to update the formatter to support alternative layouts, because currently the formatter uses hard-coded rules and always puts an array/object item on a new line. I'd volunteer to update the formatter (time to implement the second part of https://homepages.inf.ed.ac.uk/wadler/papers/prettier/prettier.pdf 🙂).

Shenglong Li (@shenglol)

Shenglong Li (@shenglol) 🙂

Part 2, pretty print with alternate patterns, would be so nice, I think the optimal/ideal solution.

The setting for grouping based on chosen width, seems to be the best of both worlds. to align with the single/multiline capability flexibility language additions in this issue.

When work was being done on ARM template JSON, the capability was implemented to allow expressions to be placed over multiple lines. After that addition, the formatter was then disabled around these function (so formatting became manual).

Stephen Weatherford (@StephenWeatherford) did some work with a UI 'toolstip' feature to show the following. No formatter was implemented, however the preview was available, which shows the nested/grouped format. (slightly different grouping/flattening than in that doc, however similar concept).

I am already thinking of a decorator to override the default width/grouping for the next line expression 😀

Adding one extra comment, with the discussions on Bicep language Param Files, it seems whatever if available in the bicep Modules will also be even more significant in the end-user interface, which are the param files formats. e.g. arrays/objects format specifically related to user configuration, which are more dynamic than the Bicep Modules themselves, so this will be most significant there.

Closing this issue out - going forwards, please create separate issues for the specific syntax that you would like relaxed line break support for:

Navigation Menu

Repository navigation

Make the language "less" newline sensitive #146

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Make the language "less" newline sensitive #146

Description

Activity

SimonWahlin commented on Nov 6, 2020

alex-frankel commented on Mar 8, 2021

anthony-c-martin commented on Mar 8, 2021

anthony-c-martin commented on Apr 15, 2021

masters3d commented on Apr 26, 2021

alex-frankel commented on May 3, 2021

11 remaining items

alex-frankel commented on Apr 1, 2022

brwilkinson commented on May 26, 2022

anthony-c-martin commented on May 27, 2022

brwilkinson commented on May 27, 2022

jeskew commented on May 27, 2022

shenglol commented on May 27, 2022

brwilkinson commented on May 27, 2022

anthony-c-martin commented on Jun 9, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions