You can drop the “if”:
If True Then
...
End
[quote=166607:@Kimball Larsen]I’ve argued ad nauseam for this in the past, and it is simply not going to happen. For me, the frustration comes not from when I have to type:
i = i + 1but rather when it’s something more like:
aVeryDescriptiveVariableNameThatIsRatherLong = aVeryDescriptiveVariableNameThatIsRatherLong + 1[/quote]
Let me see here…
i=i+1 = 5 key strokes
aVeryDescriptiveVariableNameThatIsRatherLong = aVeryDescriptiveVariableNameThatIsRatherLong + 1 = 7 key strokes
a [tab] = a [tab] +1
isn’t autocomplete great
Another tip. I like this form sometimes when I have to perform an action only if a number of conditions are true or false. I find it easier to read than a long If statement or a series of If/ ElseIf statements:
select true
case x > 1, y < 10
// Do nothing
case someOtherCondition
// Do nothing
case this or that
// Do nothing
case else
MyCode
end selectAs far as coding shorthand goes, I can deal without the += etc… I think my biggest frustration is with the dim operator. I don’t want to (nor should I have to) explicitly give the type if I’m assigning to it right away.
dim contact() as MyModule.SubModule.SubModule2.Contact = api.GetContacts()
//I should be able to write instead
dim contacts() = api.GetContacts()It’s similar to how you can currently write:
dim d as new dateinstead of:
dim d as date = new dateThe code editor shouldn’t have trouble figuring this out. It also helps code not break if I decide to change a class name or namespace location of a class when developing a library. Considering there’s no refactoring in Xojo it makes this issue even worse.
dim x =3uh… is X an Integer? if so Int8? 16? 32? 64?
or perhaps you meant it to be a double? or wait perhaps a single?
But three isn’t a method call and if the compiler can’t figure it out then it should throw an exception.
You cant call dim x as new 3 either.
Dim x = 3 would be an Auto.
[quote=166690:@Beatrix Willius]This C stuff is really horrible. Xojo is not C. I’ve been playing around with Python for the last year and I would like to see:
- case-sensitive variables (I quickly learned to use _ for variables)
[/quote]
This would be such a fundamental change to the language I think you can write that one off as “No we’re not doing this”
This would make “foo”, “Foo”, “fOo” all different - like in C
[quote=166690:@Beatrix Willius]- indentation instead of “end if” or similar (awful, awful)
[/quote]
Oh yuck
define a class return that
return a tuple
return a dictionary
lots of ways to already skin that cat
[quote=166778:@Brock Nash]
The code editor shouldn’t have trouble figuring this out. [/quote]
This has less to do with the code editor than the compiler
This would be inferred types
Not sure thats not already on the feature request list somewhere
[quote=166840:@Norman Palardy]This has less to do with the code editor than the compiler
This would be inferred types
Not sure thats not already on the feature request list somewhere[/quote]
This would be interesting if it could be implemented like “var” in visual studio.
[quote=166784:@Dave S]uh… is X an Integer? if so Int8? 16? 32? 64?
or perhaps you meant it to be a double? or wait perhaps a single?[/quote]
If you can take away something i have to worry about or write… why not? No ones saying it wouldn’t be hard to have this feature option added.
BTW I’m loving reading all the coding shorthand tips keep posting them! =).
Make this thread a huge repository of tricks, lol.
[quote=166784:@Dave S]
dim x =3
uh… is X an Integer? if so Int8? 16? 32? 64?
or perhaps you meant it to be a double? or wait perhaps a single?[/quote]
The type of the literal - in this case I’d say an integer literal
If you want something other than the inferred type you have to state it
[quote=166546:@Gavin Smith]The Xojo language is always evolving. Check out the recent if() operator. http://www.xojonews.com/news/new-xojo-if-operator.html
Furthermore, the new Xojo framework can be, in handwavy kind of way, be thought of as Xojo Language 2.0.[/quote]
Gavin
We implemented our own IIF() in XOJO years ago. Visual Foxpro had this going back to 2008 and we found it extremely useful.
[quote=167001:@Norman Palardy]The type of the literal - in this case I’d say an integer literal
If you want something other than the inferred type you have to state it[/quote]
That was my point… if you THOUGHT you were getting something other than Integer, you might introduce errors
where by being forced to specify the risk is less.
At least XOJO is flexible enough to allow implied type casting (in some cases)
dim x as integer=3
dim y as double
y=xTry that in SWIFT sometime … not so forgiving…
But… Swift does have all those short-hand operators (kind of balances)
[quote=167005:@Dave S]That was my point… if you THOUGHT you were getting something other than Integer, you might introduce errors
where by being forced to specify the risk is less.
[/quote]
I prefer the explicit typing as well then I don’t have to read the code & go “now what type IS that going to be?” and remember some rules the compiler implements.
I’d probably still write things as dim x as integer = 3
Why worry about what type it is if the language can do it for you. Plus i thought thats why you used reallyLongDescriptiveNames =). You should be able to catch it on compile if the dev tries do use it in a different manner then it was initialized for.
Mmm you’ve must not have ever tried to read/understand code you wrote 10 years ago.
10 years? Try two weeks…
Its still a valid technique that is used elsewhere. Like many of the features we are talking about… if you don’t like it you’d have the option not to use it. Personal preference wins.
Many of the things i’m talking about would giving you options when coding allowing you more options to build things that make more sense to you as an individual. Not everything works the same way for everyone so options are important. Coding is an art and should not be restricted just because someone feels this is the only way it should be done.