Use STRICT to avoid problems caused by casingMonkey Forums/Monkey Beginners/Use STRICT to avoid problems caused by casing
| Hi folks,|
do yourself a favor and start your project with the STRICT keyword. Recently I saw several questions posted where the dev couldn't figure out why his/her code didn't work. It was because he/she used different casing for his/her field names. Monkeys syntax is case sensitive. That means the field xpos is not the same has xPos.
Using STRICT means that Monkey expects you to define all fields and variables, but then complains in the translation process when a field/variable/class isn't defined. This will avoid the problems you have ran into.
So, please start every project with the STRICT keyword.
| IMO Strict should be on by default and you need to set SlackMode on ;) |
| I don't think strict should be on by default. Much like Mark I like to be lazy and non strict mode helps me proceed to do that. I've never had any problems either, so hmm...if I recall correctly, the problem you're talking about, Mike, had nothing to do with Strict mode. That is, strict mode wouldn't have helped or maybe I'm thinking of a different topic. Did the topic have anything to do with 'onCreate'?|
Note: I maintain over 25k lines of code and over 30 different classes at least. All with non strict mode.
| I agree strict should be on by default and you should need to flag it off.|
That being said I think it's bugged at the moment, I have a project with a number of includes and it seems to detect issues early on but not detect issues that are deep into the project, so even though I have strict on I still have the odd Function or method without a valid type assigned and I get no errors.
So for example my hex project the main file calls Strict, but I just looked and my UI source file should fail and does not, not sure how I could reproduce this without throwing tons of files at it tho which is why iv not posted it in the bug section.
Edit:: just thought I would throw additional Strict calls at the top of each file and now its detecting the errors, so does strict have scope only to the file ? that seems like a daft thing to me and should it not scope out to all files in the project ?
| I think the problem you're having is related to the dead code removal system. Once again has nothing to do with strict. |
| the code that should fail is not dead, I just attached a call to strict to the top of every file in my hex project and then was forced to fix I think about 45 methods and function calls spread across all the files so its not a case of a :void being missing from a function or method that never gets called.|
and if that system is prevent strict mode from being detected when it should be then it needs some work.
| Non strict does not auto-define vars or types, so in order to detect casing errors, there's not any difference. Strict forces you to explicitly return values in all of your Methods and Functions. That's mainly all it does. |
| casing errors?|
All the errors I had to fix once putting a Strict call at the top of all of my files were Function or Method returns, or some were missing () at the end of a method like List.Count instead of List.Count(), does it have casing ? i'm confused.
| Strict only forces everything to have return types and all function/method calls to be enclosed by parenthesis. It does not check for casing. |
| Strict only applies to the file. It has to be that way, because otherwise if you imported a module that was non-strict you would get errors for no good reason. |
| @Goodlookinguy yeah that's what I thought, was wondering why ziggy was talking about case..|
@Gerry thanks mate I actually had no idea thought it was a bug, but with your explanation it makes perfect sense, never though about it from a module stand point, and now that I know that I will amend my code template parser to include a strict call at the top of every file it makes.
| I was talking about case correction because of this:|
do yourself a favor and start your project with the STRICT keyword. Recently I saw several questions posted where the dev couldn't figure out why his/her code didn't work. It was because he/she used different casing for his/her field names.
| Of course, you guys are correct. Sorry for causing any confusion here. Next time I should keep quite. |
Sorry for causing any confusion here. Next time I should keep quite.Please, don't be quiet. that thread explains a bit how the Strict mode works. I don't think generating documentation and constructive discussions is a bad thing!