What does SuperStrict mode do?
BlitzMax Forums/BlitzMax Programming/What does SuperStrict mode do?
| ||
| The docs say: "Set SuperStrict mode", which is extremely descriptive (NOT!). What additional programming requirements are, er, required with SuperStrict mode? (And could the answer to this question be put in the docs?) Russell |
| ||
| I can't find the post where Mark said what it does, but I know, so it doesn't matter. Anyhow, SuperStrict requires you to specify the data types for everything (globals, locals, etc.). If a function does not have a return type, it is presumed to not return anything, so if you return anything from a function without a return type you'll get a compiler error. It's seems excessive, but having SuperStrict on all the time will make you get into the habit of declaring everything appropriately. |
| ||
| I second that. About 75% of my errors due to stupid mistakes were because declaration was improper (or non existant) in my code. Get into the habit! It cant hurt! (well, it can hurt if you grab someones code thats already been done in plain old Strict mode, but you can always convert) :) |
| ||
| SuperStrict stops dead most typo errors before they even happen! *very* useful and it kills the evil goto stone dead! |
| ||
| It certainly makes you a more disiplined coder. I usually activate it later on in my code only to be faced with BlitzMax waving it's finger tut tuting at all my errors. SuperStrict is almost like receiving your course work from the headteacher then looking for that "SEE ME!" underlined in red! |
| ||
| yeah but tracing a typo like blobx:+1 v's bl0bx:+1 is no fun with some fonts! |
| ||
| Doesn't Bmax highlight the errant line? ;) I propose SuperDuperStrict mode, where your code must also be indented and all functions prototyped! Naw, not really... Russell |
| ||
| The stuff which was mentioned is already part of strict. SuperStrict enforces type declaration, which strict doesn't ie local a isn't allowed anymore, it must be either local a% or local a:int The same goes for function / method return where you must explicitely define a return type if you want to return something. SuperStrict is good if you want to enforce the correct type behavior within your project. |
| ||
| yeah but tracing a typo like blobx:+1 v's bl0bx:+1 is no fun with some fonts! maybe if you'd type it like blobX instead of blobx, and get used to this type of accepted notation... then, the differences between caps, lowercase, and numerals might be more easily spotted... ... just a suggestion. --Mike |
| ||
| yeah but tracing a typo like blobX:+1 v's bl0bX:+1 is no fun with some fonts! I agree, so far I've gone with Strict which captures them but am coding function returns etc so might as well go Super. Red, I'd find it difficult to spot blobX vs Bl0bX as well. My favourite is typing lsit rather than list and, for some, reason, my brain fills in the gaps when I'm reading it (as we know it can from stuff like this this ). Still, be nice to have it documented even if it's just one line of explanation |
| ||
| You can avoid the "o 0 , l I 1" confusion by using a font that is easy to distinguish. My current favourite is Bitstream Vera Sans Mono. I and 1 are slightly similar, but the 0 has a dot in the middle, which has always been a favourite feature of mine when it comes to computery fonts :) |
| ||
| or just use superstrict and not have to worry at all... |
| ||
| You can avoid the "o 0 , l I 1" confusion by using a font that is easy to distinguish It doesn't matter, if the error is 'somewhere' in hundreds of lines of code, these things are difficult to spot no matter what font you are using. Strict just nukes these problems right out the water. |
| ||
| There are other things Strict does like giving local variable scopes (these do not exist without strict) |
   |