Indeed.
It's not just a matter of gofmt: the "implicit semicolon" rule of Go syntax
is triggered at the end of this line
```
if Variable1 == true
```
causing it to be parsed as
```
if Variable1 == true;
```
Any operator in the following line arrives too late to change that.
So to implement what you propose, Go syntax rules would need to be changed.
While they are not set in stone, the added convenience of your new syntax
is probably too small to justify a language change (just my opinion - feel
free
to propose such a change to Go developers)
On Thursday, October 31, 2019 at 9:39:35 PM UTC+1, Ilia Choly wrote:
> Your code doesn't even compile.
>
> On Thursday, October 31, 2019 at 1:13:50 PM UTC-4, kevma...@gmail.com
> wrote:
>>
>> I apologize for submitting yet another go format "issue". I'm more so
>> gauging the community on this idea. Furthermore, I ask that you understand
>> I'm not sure if this type of code format has a proper name to it, I'm just
>> calling it "newline-operator-chain" (in contrast to
>> "operator-newline-chain").
>>
>> ...For the record the first time I saw this type of formatting was when I
>> was using SQL Server Management Studio 2012. It had formatted its `select`
>> statements in a similar way. Though I normally hate Microsoft's ways of
>> doing things newline-operator chains look much cleaner. Enough talking,
>> it's best I just show what I mean:
>>
>>
>> operator-newline chain
>> if Variable1 == true &&
>> Variable2 == 5 &&
>> MakeSureICan() {
>> // ...
>> }
>>
>>
>>
>>
>> LotsOfArgs(myArg,
>> anotherArg,
>> bonusArg,
>> thisArgToo())
>>
>>
>> newline-operator chain
>> Much cleaner in my opinion.
>> if Variable1 == true
>> && Variable2 == 5
>> && MakeSureICan() {
>> // ...
>> }
>>
>>
>>
>>
>> LotsOfArgs(myArg
>> , anotherArg
>> , bonusArg
>> , thisArgToo())
>>
>>
>> Why Go format needs this
>>
>> *Looks cleaner, looks simpler*
>> I believe that the newline-operator chain formatting looks niced due to
>> the lining-up of the operators. This is nice to Go programmers like myself
>> who are obsessed with readability. For instance, one could much understand
>> the purpose of each argument in a faster manner when scanning through
>> newline-operator chains as the operation is specified before the argument.
>> Compared to operator-newline chains where the reader must look at 2
>> separate lines to fully understand the role an argument plays in the chain.
>>
>> *Makes more mathematical sense*
>> And I think is more suitable for the underlining "mathematical" nature of
>> operators in the first place. A good chunk of *any* programming is math,
>> thus any language should share as many aspects with math as possible.
>> Forcing operator-newline chain formatting disobeys this property.
>>
>> We'd see this in math:
>> 2
>> + 4
>> + 9
>> - 1
>> ----
>> 14
>>
>>
>> not:
>> 2 +
>> 4 +
>> 9 -
>> 1
>> ----
>> 14
>>
>>
>> The latter (operator-newline) looks confusing and harder to follow, the
>> readability is lacking. Which is why I think we need to allow the former
>> (newline-operator) in Gofmt.
>>
>>
>> In my opinion, I think Gofmt needs to *disallow* operator-newline to
>> achieve the highest grade of readability.
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3da3aaf1-de3b-422c-9dfc-7af47dd28855%40googlegroups.com.
