From the Xojo blog:
I would disagree, especially when you have multiple functions inside each other:
Str(Max(Min(x,Abs(y)))) is far less readable for me than Str( Max( Min( x, Abs( y ) ) ) )
Or more complex ones. Spacing makes it easier to see what belongs together.
There are no comments on the blog page.
I would disagree. There are no comments yet, but you can certainly add your own:
I agree with Markus. I often put extra spaces to make sure I got the parenthesis right. But I guess this is a question of personal style.
I also cannot leave the equal sign stuck between variables. I systematically do a = b, NOT a=b.
One of the few things I loved about VB6 was that it would give you consistent spacing within a line of code. I miss that functionality.
Might also have something to do with age as my eye sight isn’t the best, and I find bunched up code much more difficult to read and follow. Especially ))))) how many parenthesis are that again?
Funnily enough in xDev Tips&Tricks I argued FOR spacing 
Nope. Might it have something to do with me reading it on an iPad?
Dito.
Take a peek at Format Code, GitHub - jcowgar/xojo-format-code: Code formatter written in XojoScript for Xojo
In regards to spaces or not, it’s an endless debate and Kem may find this hard to believe, but I think there is no right answer. If you were raised on southern corn bread, it’s far better than anything you’ll find in the north. Raised on northern corn bread? The southern stuff stinks!
You get use to what you see and anything different is harder to read. I personally looked at the example:
Str(Max(Min(x,Abs(y))))
// vs
Str( Max( Min( x, Abs( y ) ) ) )and was immediately confused at the later. Trying to parse all that information in my head. It looks like a complete mess to me. My head just doesn’t work when reading it. Why? Because it’s the wrong way to code? No. Because I’m not use to it. The first line of code in that example is cake to read. I can read it without even thinking. The second line, I actually wind up scanning the line forward and back.
Now, that being said… I actually think both of those lines are wrong, but not because of the parens but because anything deeply nested is hard to read, hard to debug.
Also, you guys are forgetting that there is a crowd out there that would prefer
Str ( Max ( Min ( x, Abs ( y ) ) ) ) )Are they wrong? Nope.
One more thing… The only way there is a wrong or right is if there is a set standard for the project you are working on. If your project says no spaces on the inner parens, then it’s wrong.
Another way it’s wrong, is if the community has a standard (written or not). It’s nice to write code that the community can easily read, understand, use and share. If the community has 10 different formatting standards, it’ll be a community that will have problems growing.
Spaces or not, that many parens is hard to comprehend at a quick glance, thus shouldn’t happen in real code. Refactor and that reasoning becomes invalid.
One liners like
dim s as string = foo.ReplaceAll("a","").Trim().replacelineendings("") ...... and so on should be avoided
that you CAN do something like this doesn’t mean you SHOULD do something like that
I’m surprised it actually works - doesn’t max require two arguments?
Isn’t all a matter of taste though? Consider this
If x = y Then
Return True
Else
Return False
End If
Return x = yReturn If(x = y, True, False)All three do the same job, but the first example allows you to set break points on the return value - very useful when debugging, and with autocomplete the difference in the number of keystrokes is minimal.
To me code readability is the most important consideration, and that is rather personal. The C type languages all look like bovine fertilizer to me due to my commercial experience with COBOL.
If x = y Then
Return True
Else
Return False
End Ifthis is correct style
the rest … bovine 
You can see the return value on a method such as
return x = yPut a break point on the return and then step in on the the return. The debugger will show what the return value is.
You make a point, but what if I only want to break on True or False. The first example gives me the most flexibility to debug my project and I doubt there’s any optimization difference between them.
You can see it
The line just isn’t quite as simple to read as “return true”
Its why we often get questions about some code that is like
dim b as boolean = x = y[quote=246420:@Norman Palardy]You can see it
The line just isn’t quite as simple to read as “return true”
Its why we often get questions about some code that is like
dim b as boolean = x = y[/quote]
That should be written as:
dim b as boolean = (x = y)
Again both return the same result, but one is slightly more readable to an experienced programmer who is used to that technique of coding.
@Markus Winter I’m sorry we’ve stolen your thread, but perhaps not - code readability is really the topic?
[quote=246421:@Jeremy Cowgar]That should be written as:
dim b as boolean = (x = y):-D[/quote]
The fact that so many folks are confused by that idiom, with or without parens, assures me that writing code that is highly readable is MUCH more important that trying to write code that is dense so “it runs fast”
Been there done that and had to audit my own code literally 10 years later and was darned glad I wrote using long variable names, explicit if then else’s instead of some of the cool short cuts the specific language in question allowed
I’d still be there picking it apart if i had
And even after 10 years fixes were easy
Remember that in 6 mos there may be some crazed psychopath who has your home address that has to READ and fix your code.
Write accordingly
Just a compare/contrast.
In Swift… this is legal
a=b
a = bbut this is NOT
a= b
a =b