and if you are schizophreic, the psychopath may be YOU
I pride myself in writing readable code, I always felt a simple comparison on a return statement was the cleanest, most readable way of writing the code. Now, complex comparison? No way.
To me overly verbose code is hard to read. There are happy mediums, I think. Code clutter is a bad thing, IMHO. Now, doing some code golfing? No. One should not try to write code as concise as possible, one should try to write code as clear as possible.
What would you say to this fictitious code, the idea is multiple assignments to some object instance, nothing more.
response.FullName = user.Name
response.Email = user.Email
response.IsAuthorized = (HasAccount and IsActive)
response.LoginAt = new Date
response.PrimaryGroup = if(user.IsAdmin, kAdmin, kNormal)vs.
response.FullName = user.Name
response.Email = user.Email
If HasAccount and IsActive then
response.IsAuthorized = True
else
response.IsAuthorized = False
End If
response.LoginAt = new Date
If user.IsAdmin Then
response.PrimaryGroup = kAdmin
Else
response.PrimaryGroup = kNormal
End IfBTW, is return (a > b) faster than a If/Then/Else? i.e. your comment “runs fast.” Had no idea.
Both lack whitespace and comments 
For ME either would work
But I’m unlikely to be the person that inherits the code & has to fix it or update it
Write for that person
I tend to assume they are brand new to the language
I break up code into logical blocks, typically with comments on top of the block of code. If I have an “assignment” block such as my response.XYZ = ABC, I do not break that out unless I wind up having to perform anything but simple logic that will go on one line.
Personally, however, I’d rather inherit the first form, than the second form. Even if there were comments and white space.
About assuming they are brand new to the language. Maybe that’s where we differ a bit. I work with other very experienced Xojo developers. You do as well, of course, but you also provide support here for the Xojo Language to everyone. We attempt to code for clarity, readability and testability. Then, if necessary, we go back and update for any performance issues that occur (rarely ever).
[quote=246428:@Dave S]Just a compare/contrast.
In Swift… this is legal
a=b
a = bbut this is NOT
a= b
a =b
[/quote]
Which strikes me really odd that it does that
[quote=246434:@Jeremy Cowgar]I break up code into logical blocks, typically with comments on top of the block of code. If I have an “assignment” block such as my response.XYZ = ABC, I do not break that out unless I wind up having to perform anything but simple logic that will go on one line.
Personally, however, I’d rather inherit the first form, than the second form. Even if there were comments and white space.
About assuming they are brand new to the language. Maybe that’s where we differ a bit. I work with other very experienced Xojo developers. You do as well, of course, but you also provide support here for the Xojo Language to everyone. We attempt to code for clarity, readability and testability. Then, if necessary, we go back and update for any performance issues that occur (rarely ever).[/quote]
I learned this the hard way.
Assuming the next guy is at least as smart as I am or experienced as I am did mean that I had a call years later asking me about code I haven’t got in front of me.
I felt quite … bad … that I had left code that someone else could not figure out - and they were not new or dumb.
It was just written suing some obscure language feature and the machines & runtimes etc were being updated and things no longer worked. (YAY!) Turned out the vendor had updated things in a way that obscure feature was no longer available (DOUBLE YAY!)
I literally had to go in, reread the old vendor docs, and decipher my own code to realize this was what was happening.
Fortunately we could update to do the same thing in a slightly different way.
It also ended up being more understandable to the new guy (thank god) as we rewrote the code. (Yes WE)
Ever since every place I’ve ever done work for or worked at I assume the next guy is “new” - new to everything.
Expecting the next guy is at least as experienced or as smart as you is where problems arise in the event that guy isn’t.
Clear, straightforward, easy to follow code is a god send = now and into the future.
Now that doesn’t mean code is simplistic or that complex problems are avoided.
Complex operations will necessarily be complex.
But decomposing the problem into manageable pieces and writing those pieces in a clear way is requisite.
I think that is all Wayne & I were suggesting.
And FWIW either of those code samples would be OK by me
The second turns out to be more “debuggable” as I can easily break only on the true or false paths which you cannot do with the one liner forms
That makes sense, I guess I just don’t view
return (a = b)as complex code. I’d hate to code on a level lower than that understanding.
its not
but debuggability of code should also factor in when you write it
yes you can inspect the return value
but if you only want to break when you return false you have to rewrite the code
you dont with an if then else
IF it were more complex than that simple comparison how would you be sure that what rewrite you have to do hasn’t altered the test in some subtle way ? perhaps altered something that, by side effect, now works when it didn’t used to ?
this HAS strayed from “style” - “do you put spaces around before after ( )” to “how do I write maintainable code” which isn’t the same thing. I’ve seen code that conformed to some VERY rigorous style guidelines that was complete crap and unmaintainable. And stuff that didn’t conform style wise but was nice & maintainable. Applying the style guidelines was easy,
Your exactly right, and I’ve had to rewrite a condition to check it as you state. Not often, and for readability, I still prefer to write in the above manner. When debugging code, If it is anything more than a simple comparator, I normally wouldn’t write a return like that. Won’t save I never have, but rarely.
yeah… strange… XCODE gives error “Prefix = is reserved” or “Postfix = is reserved”
same thing with a few other operators… like != (same as XOJO <> )
if x!=3 {} // not legal
if x !=3 {} // not legal
if x!= 3 {} // not legal
if x != 3 {} // legalat least Xcode tells you this the instant you type it… but the use of whitespace in certain circumstances is weird.
I’ve seen ones that are not much more extensive (names have been changed to protect the guilty parties)
return c or (a and b) more or less
BUT - and this is a style thing, C was a function call (to a global method) … not obvious from how the code is written
And it turned out that simply changing that to
return (a and b) or cran a ton faster because (a and b) were locals that allowed the entire statement to be short circuited very quickly and very frequently so it skipped the evaluation of the function call entirely
Since Xojo is SO forgiving about parens you can hide these little details
ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS use parens for method calls !!!
There are a few things like this that the language lets you get away with that can result in hard to track down bugs where WE as writers have to help ourselves
[quote=246445:@Norman Palardy]ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS use parens for method calls !!!
[/quote]
That’s an interesting one! In the project I am working on right now, we have a mixture of this. I’m guilty of inadvertently spreading to other developers the habit of not using parens. It recently came up in a discussion about we need to create a standard. Code that is the same as the rest of the project’s code is much easier to read. So, this is very timely, for me at least.
When I began thinking about it, not using parens became an anti-pattern because it means you have code in some sections that have parens (because they must for lexical reason) and code in others that do not have parens. Thus, you’re back to a project where the code looks different in different areas, which I’ve always felt was bad.
What are your reasons for ALWAYS, ALWAYS, … use parens? For me it came down to consistency, but there are a few places where it could make writing a bug easier as well. Have not shared my feelings with the team yet, but curious as to yours.
[quote=246443:@Dave S]yeah… strange… XCODE gives error “Prefix = is reserved” or “Postfix = is reserved”
same thing with a few other operators… like != (same as XOJO <> )[/quote]
I have not used Swift before, but is it like ruby where you can use some “special” characters as part of the method name, such as ?, ! and = (the later not so much so, but almost)?
No… Swift allows all kinds of strange characters in variable/method names (such as 
) , but ! and ? have special meaning(s), depending on context… I still don’t have my head wrapped around the rationale, so far I just let Xcode tell me to change it
See, we don’t care one way or the other on this. Always seems a bit too strict in this case.
Visually inspecting code you cant tell whats a method and whats a property
Adding the () gives that distinction
Now there IS a downside IF you frequently swap between something being a method or a property or constant
IF you always include the () then you will get warned if you move something from being a method to a property / constant
But, IMHO, that is a small price to pay for being able to read the code and know without having to go hunting all the time
Definitely a trade off
So you would add parens to this?
while not rs.EOF()
blah
rs.MoveNext()
wenda = b I don’t see this at all, brain makes me think
a=b instant parse, no thought at all
adding spaces just eliminates all readability for me, and when I write code 80% or more is comments and notes, I don’t want to reduce the amount of information, just to make it readable, whitespace is not good for that, it kills all readability for me.
I do like parenthesis, thats very nice! always xxx.close() or return(), select case(1).
but I really do not like “end if” as opposed to “endif”, that is just an almighty pain, why on earth is there a difference? that makes absolutely no sense to me.
[quote=246428:@Dave S]Just a compare/contrast.
In Swift… this is legal
a=b
a = bbut this is NOT
a= b
a =b
[/quote]
This is exactly the kind of thing I HATE (fiercely) in Objective-C that seems to linger in Swift. The user interface is sloppy. Once again, some ■■■ engineer decided to force humans to adapt to the machine, instead of taking into account human notation. For no reason other than laziness, I think. How difficult would it have been to parse with either ?
Note:
when you have an error - say on the number of open / close parenthesis -, the IDE sometimes report a wrong (IMHO) text.
Done from (bad) memory: I do not have the example in mind, but now, if I have an error and tehre are parenthesis in the code line, I start seeking parity (between open / close parenthesis).
At last, I try to avoid one liners like hell because of the increased number of potential writing and reading errors (from me).