Please please please write better blog posts when they deal with examples.
The biggest problem: describe what and why you are doing something. Never ever just do some code dumping. “Copy this code here”. I want to learn something. The last blog post was about bit shifting. I’ve never used that so an explanation what bit shifting is would have been helpful. The Active Words tutorial could have explained the delegate and how the code for finding the words work.
Make sure that the code you do actually works. The Active Words tutorial has a NOE and the new version has a one-off error that wasn’t in the old version.
Usually the code quality isn’t good. Representative line from Active Words:
The thinking about the meaning of the code alone means it isn’t good code. That’s why I called it representative line. The rest of the code isn’t really better.
Hmm. I just write about stuff I find awesome & hope others get something out of it. I do find looking at the examples, that others have different coding styles & wonder why, but if I analyze the process I find I do learn new things some of which I will integrate into my coding style.
The post wasn’t so much about coding styles but the approach. As Xojo is going after the “new user” segment the blog posts should reflect that and not simply present the how but give much more background on the why, and why that way and not another way.
Come to think of it, that’s true whether it is aimed at beginners or not.
As for
cstart = If(cstart - 1 < 0, 0, cstart-1)
This is unnecessarily complicated and if you MUST use single line ifs should be
cstart = If(cstart < 1, 0, cstart-1)
Seems someone confused himself (or herself) which is easy to do with these single line ifs …
Xojo blog posts are written and reviewed but we’re all still human and mistakes can slip past. If you think you found an error, please let me know and I can look into it. If you have another way to code a solution, feel free to write a post about it. We all know in code there are often multiple solutions and I’m happy to present them. I love to highlight the different voices of Xojo and encourage guest posts and alternate solutions. It takes courage to write something and present it publicly and I ask you to consider some respect or at minimum, some kindness. Contacting the author or me is more helpful than a blanket statement like “write better blog posts”. The bottom of the post has 2 links on how to contact the author if you wanted to suggest a change or foster a discussion on their methods.
People share Declares for iOS here all the time. But there’s never been a tutorial on how to create one that I know of. I’d like to see that, starting from Apple documentation to XOJO code.
Using MAX is clearly better than the IF for this situation. Using 5 lines of code in the suggested IF THEN is completely unnecessary. 5 lines of code I don’t want to look at when IF is so concise. If the first expression is true, the second expression is assigned to the var, otherwise the third one is. Very understandable (and expressed better by some folks in the thread - the original IF was awkward). Still, not as good as MAX for the example. But sometimes we momentarily forget things and later you look at it from a fresh perspective and you say “WTH?! Why didn’t I use MAX?”
And then there’s the issue of boolean logic which a lot of people don’t seem to fully grasp. One of my pet peeves is:
A = IF(B > C, true, false)
when all you need is
A = B > C
(I did A = B = C one time and confused the hell out of my boss, but it’s a very simple line of code. That line would, admittedly, be slightly more clear in Pascal)
Another is “spelled out,” unnecessary code:
OkToContinue = true (this is fine)
later in the code it’s:
if OkToContinue = true
when all you need is
if OkToContinue
Simplify . . . sometimes that means more code and sometimes it means less code.