Strict mode and warnings
Monkey Forums/Monkey Programming/Strict mode and warnings
| ||
| A few random thoughts about strict mode... Strict mode could (and Java/C# users would probably say should) be stricter. Also, the analysis done by strict mode could also be useful to non-strict users. In particular, Java doesn't allow ANY unreachable code, and both Java/C# don't allow 'implicit conversion to bool', eg: You can't just go 'If x', you have to go 'If x<>0'. Also, float/int conversion rules are generally stricter in Java/C#. When I put some of these ideas to the beta testers back in the day, they were all pretty much against these ideas, considering them too strict I guess. Yet there have been posts here since that suggests not everyone agrees. With that in mind, here's an idea: 1) Introduce 'warnings' to Monkey 2) Add syntax, similar to the current 'Strict', that turns warnings into errors on a per source file basis. Here are the warnings I'm thinking of: 1) Implicit int type declared (eg: "Local x") 2) Implicit return statement declared (eg: missing return statement) 3) Implicit float->int conversion (eg: Local x:Int=10.0) 4) Implicit bool conversion (eg: If x Then...) 5) Unreachable code One option for converting warnings to errors would be to allow a warning level value after Strict, eg: Strict 2 'Warnings 1..2 are now errors! ie: the current strict mode (and default for Strict with no arg). ...or... Strict 5 'Warnings 1..5 are now errors! SuperStrict! Ok, yes, this is very C++ inspired, but it would allow for a wide range of coding preferences while also providing some possibly useful warnings - which should also be disablable via the IDE for slobs like me. I've tried to sensibly 'tier' the warnings, but it might also be possible to enable individual errors with different Strict syntax too. The numeric scheme is pretty ugly, but is at least brief. I'm not actually quite sure what I think of this! |
| ||
| Will compliance with strict 5 make code execute quicker? if not then i don't really see the point beyond pandering to the whims of 'geeks'. |
| ||
| IMHO just keep Strict and add SuperStrict which is Strict 5. Or just get rid of the keyword Strict and make the language Strict 5 by default >:) |
| ||
| @therevills: Or just get rid of the keyword Strict and make the language Strict 5 by default >:) This. :) Mark rather than creating some arbitrary number of warnings, it might be better to assign a numeric severity level to each type of warning, and put it in the trans configuration file. Then your "strictness level" would cause compile warnings/errors for any conditions with a severity level <= that number. This way, warnings can share a severity level. |
| ||
| This. :) What he said.To add to that, while I think that static (and dynamic) code analysis is a valuable tool to identify bugs and performance bottlenecks (and is one of my main reasons for thinking IntelliJ is awesome) I really, really wish you wouldn't write your own software from scratch every time, but maybe instead built it on top of something like [a http://www.scovetta.com/yasca.html]Yasca[a] for example. Will compliance with strict 5 make code execute quicker? Yes. One major point of static code analysis is exactly that. Identifying bottlenecks (complex boolean expressions for example) that can be written more elegantly. Whether Mark intends to take it to that level is another matter entirely. Right now it seems (from what I can read) like he mostly wants to make a Monkey version of lint, which won't benefit you much in the performance department. |
| ||
| I like having to be forced to write nice code, but it's annoying when the examples, etc.. are not "nice" code. That being said, if you haven't looked already I posted an issue in the android forum and the sticky in the new release about Abstract methods not returning anything and Java freaking out because of it. One thing that I do wish we had language-wise was php-style arrays, where you can nest multiple types of values as keys, and multiple types of values as values. There are obvious workarounds, but they're still nice! I do enjoy the more advanced features/OOP encapsulation like Java/C#. I <3 Monkey, keep up the good work! |
| ||
| One thing that I do wish we had language-wise was php-style arrays, Please. God. No. |
| ||
| I think adding SuperStrict which represents level-5 of warning should be enough and wil be easy to understand by beginners. Strict Mode should really be default imo, maybe introduce the 'Lazy' keyword for those who don't like Strict mode. |
| ||
| wil be easy to understand by beginners. How many "beginners" is Monkey really going to appeal to tho'? It ships with a mostly useless IDE virtually no documentation, a handful of examples and forum access to get you started. Additionally you need to have significant knowledge about your target platform(s) if you want to try anything remotely advanced (like SaveState).Could we please not dumb down the language for the scores of imaginary beginners Monkey doesn't appeal to anyway? Beginners are going to chose something like Unity3D which holds your hand all the way. Whether you want it to or not. I mean seriously look at people here. James Boyd has been programming in all the time I've known him. Which is at least the last 20 years. Back when the Amiga ruled the world and a 56K baud modem was the best Internet connection money could buy. GfK worked for Gremlin Graphics (granted, not as a programmer AFAIK), but how many people even remember Gremlin Graphics (or even Infogrames)? Seriously most people here have been programming for longer than their prospective customers have been alive. Mark Sibly wrote his first game nearly 30 years ago. Can we please stop pretending everyone is a beginner? Thank you. |
| ||
| Agree. 'Basic' has been left behind by Max and more so by Monkey. Let's not try to go back. |
| ||
| What I meant was not to make things unneccessarily complex, for both Mark and the Programmer. Either you get all the warnings or not. So Strict + SuperStrict should do it ... I was more against the Idea of the level of warnings system. |
| ||
| @FlameDuck: ...but how many people even remember Gremlin Graphics (or even Infogrames)? The original Alone in the Dark games were AWESOME! :D |
| ||
| I have stopped to use strict these days just because it does not do what I want it to. I want two things: 1. That my code can be clear and easy to read 2. That the compiler catches 'obvious' misstakes I make There is a balance to be struck when debugging time is great in relation to that you need to write to much extra code that does little. This just my opinion on it: 1) Implicit int type declared (eg: "Local x") I want this rule enforced 2) Implicit return statement declared (eg: missing return statement) This rule I want, but I feel VOID is the logical thing for method-returns to have if the return type is left-out, not default int. However I can happily live without this rule since it rarely results in complex bugs imo. 3) Implicit float->int conversion (eg: Local x:Int=10.0) Unless boxing takes place, I want no warning for this, since it often just results in cluttered casting-code from my experience in C#. I have not found this a source of many errors anyway. 4) Implicit bool conversion (eg: If x Then...) I want no warning for this. This is one of those very neat things with Monkey. I just love that you can also do this with Objects to see if they are null. PLEASE: However I do not like that Then is allowed to be used when the If-Statement is NOT a one-liner. Also I do not like that Then can be omitted when the if-statement is a one-liner. Not only does it **** up intellisense and syntax parsing, it also makes code LESS clear in my opinion and less consistent - though it seems *most* monkey users use 'Then' on single-liners and not otherwise. So that is why I think enforcing this ALWAYS would not be a pain for many, but it would give the community more readable monkey code. 5) Unreachable code I want a warning for this, if the compiler is accurate in determining this. It would also be nice if the compiler could generate some optional compiler response on the methods,fields,classes,modules that were actually translated, so that "unused" areas of the code can be highlighted by editors such as Jungle. One thing I like very much in Monkey is that parentheses can be omitted. This makes a lot of code super neat, and if any kind of strict would force me to write unnecessary parenthesis again I'm happy to live without strict. I like the concept of Warnings. Instead of "errors" I can get info that certain files *might* contain something suspicious or out-of the normal and if I can toggle them off from the editor (using compiler options) even better. And with warnings everything could still compile - I just get notified of the trespassing - also very easy for an editor to pick up and show these. |
| ||
| GfK worked for Gremlin Graphics (granted, not as a programmer AFAIK), but how many people even remember Gremlin Graphics (or even Infogrames)? Correct. I worked for Gremlin Interactive from 1998, until 2001 when Infogrames bought them out and promptly sacked everybody.I did a brief but exhausting stint (6 months or so) in QA, and the rest in motion capture. I also did some stuff for them in Visual Basic 6 but I'd been programming on the Amiga since the early 1990s and had my first game published in 1994 (which is partly what got me the job in the first place) and Amstrad Locomotive Basic back to 1986. This is my 25th year of programming (and so far, the best!) |
| ||
| OT: Hmm, I wrote to Gremlin around 1997/1998 over something to do with the MASK game, I imagine, on the Amstrad (I *really* liked Locomotive Basic!) and they sent me a load of free stuff... probably wasn't you, though... |
| ||
| Nah, we weren't allowed contact with the outside world! |
| ||
| unreachable code warning sounds good, the other warnings I dont mind about really |
| ||
| One thing that I do wish we had language-wise was php-style arrays, Please. God. No. Please. God. No. +1 I would love this kind of warnings added to the compiler and, while you're at it (Mark) it would be also absolutelly nice if the compiler does not provide only the first compilation error it gets. A complete list of errors would be much more elegant IMHO. And the idea of making it just superstrict with errorlevel 5 or something like this... well, I see no point in giving all warinings the same level of importance. It's not the same to let an implicit bool conversion in a IF sentence than to forget to return a value in a non void function which could mean the function does not provide proper execution results and produce harder to maintain code in the long run. The more flexible and configurable the warnings thing is, the better. Now, a personal thought (take it or leave it, I'm trying to be constructive): I do agree Monkey is not a beginners language but it is high level enough to be sold to beginners with a good IDE or editor, better documentation and more and better examples. Maybe it would be a good idea to have a "monkey samples" section in the forums, so we all can contribute and, every once in a while, someone at BRL could collect the best samples and game demos and add them to the Monkey mojo demo, etc. Marketing, you know... :D hehehe By the way, by the best samples I mean the best looking samples, not the best samples to learn the thing (the idea is to sell the Monkey first, and the look and feel in the very first impression is deterministic). |
| ||
| while you're at it (Mark) it would be also absolutelly nice if the compiler does not provide only the first compilation error it gets. A complete list of errors would be much more elegant IMHO. Indeed agree on this! |
| ||
| Indeed agree on this! Me too! |
   |