Over many years and many Info Exchanges, the OpenEdge community has requested improvements to the ABL Compiler. Product Management has requested that Development evaluate the addition of a “strict” option to the COMPILE statement. I would like to solicit your input on this improvement.
I will assert that the “strict” mode on the compiler would instruct the compiler to generate an error if any of the set of conditions is encountered. So, which specific actions would you want to see in a COMPILE “strict” mode? Several actions for your consideration:
(1) Disallow the use of abbreviations for all ABL keywords. For example: DEF VAR iCnt AS INT. would no longer compile when using the compiler’s strict mode.
(2) Disallow the use of abbreviations for database objects. For example, the compiler would no longer allow a program to use the shortest unique identifier for a field in a table.
(3) Require all database references to be fully qualified, database.table.field.
(4) Identify all unreferenced variables and properties.
(5) Identify any code section which cannot be executed.
(6) Identify if a user-defined function or non-void method does not contain a RETURN statement. Do you expect the Compiler to perform code path analysis and therefore confirm that ALL code paths have a RETURN statement?
(7) Other scenarios?
For whatever set of tests we conclude constituting strict mode compilation, do you want the ability to choose the specific set of tests you want the compiler to enforce? Do you want a ‘enforce all’ option? If we added additional checks in future releases would it be acceptable if the ‘enforce all’ executed more choices in a future release?
Any other thoughts you have on this change are greatly appreciated.
Thanks
Evan Bleicher
Over many years and many Info Exchanges, the OpenEdge community has requested improvements to the ABL Compiler. Product Management has requested that Development evaluate the addition of a “strict” option to the COMPILE statement. I would like to solicit
your input on this improvement.
I will assert that the “strict” mode on the compiler would instruct the compiler to generate an error if any of the set of conditions is encountered. So, which specific actions would you want to see in a COMPILE “strict” mode? Several actions for your consideration:
(1) Disallow the use of abbreviations for all ABL keywords. For example: DEF VAR iCnt AS INT.
would no longer compile when using the compiler’s strict mode.
(2) Disallow the use of abbreviations for database objects. For example, the compiler would no longer allow a program to use the shortest unique identifier for a field in a table.
(3) Require all database references to be fully qualified, database.table.field.
(4) Identify all unreferenced variables and properties.
(5) Identify any code section which cannot be executed.
(6) Identify if a user-defined function or non-void method does not contain a RETURN statement. Do you expect the Compiler to perform code path analysis and therefore confirm that ALL code paths have a RETURN statement?
(7) Other scenarios?
For whatever set of tests we conclude constituting strict mode compilation, do you want the ability to choose the specific set of tests you want the compiler to enforce? Do you want a ‘enforce all’ option? If we added additional checks in future releases would
it be acceptable if the ‘enforce all’ executed more choices in a future release?
Any other thoughts you have on this change are greatly appreciated.
Thanks
Evan Bleicher
Flag this post as spam/abuse.
I definitely would not want #3. I have the opposite standard whenever possible of never qualifying if possible so that I don't have to muck around with aliases. I think you would find the feature much more popular if people could turn on and off individual features. I think, for example, that there would be [misguided] people who would want to abbreviate keywords, but not database objects.
But, hey, bring it on!
Mike, I think you raise a couple of important points. One is that one would not want this to make development awkward. The other is that one might want the option for the whole think to be a warning or fatal. Perhaps each option could be 0, 1, or 2 for Ignore, Warning, Error?
1. Do it.
2. Do it.
3. Maybe extra strict mode?
4. Do it.
5. Doesn’t it do that already?
6. Do it. No.
7. What Mike Fechner said.
Over many years and many Info Exchanges, the OpenEdge community has requested improvements to the ABL Compiler. Product Management has requested that Development evaluate the addition of a “strict”
option to the COMPILE statement. I would like to solicit your input on this improvement.
I will assert that the “strict” mode on the compiler would instruct the compiler to generate an error if any of the set of conditions is encountered. So, which specific actions would you want to see in a COMPILE “strict” mode? Several actions for your consideration:
(1) Disallow the use of abbreviations for all ABL keywords. For example: DEF VAR iCnt AS INT.
would no longer compile when using the compiler’s strict mode.
(2) Disallow the use of abbreviations for database objects. For example, the compiler would no longer allow a program to use the shortest unique identifier for a field in a table.
(3) Require all database references to be fully qualified, database.table.field.
(4) Identify all unreferenced variables and properties.
(5) Identify any code section which cannot be executed.
(6) Identify if a user-defined function or non-void method does not contain a RETURN statement. Do you expect the Compiler to perform code path analysis and therefore confirm that ALL code paths have a RETURN statement?
(7) Other scenarios?
For whatever set of tests we conclude constituting strict mode compilation, do you want the ability to choose the specific set of tests you want the compiler to enforce? Do you want a ‘enforce all’ option? If we added additional checks in future releases would
it be acceptable if the ‘enforce all’ executed more choices in a future release?
Any other thoughts you have on this change are greatly appreciated.
Thanks
Evan Bleicher
Flag this post as spam/abuse.
Thread created by Evan BleicherOver many years and many Info Exchanges, the OpenEdge community has requested improvements to the ABL Compiler. Product Management has requested that Development evaluate the addition of a “strict” option to the COMPILE statement. I would like to solicit your input on this improvement.
I will assert that the “strict” mode on the compiler would instruct the compiler to generate an error if any of the set of conditions is encountered. So, which specific actions would you want to see in a COMPILE “strict” mode? Several actions for your consideration:
(1) Disallow the use of abbreviations for all ABL keywords. For example: DEF VAR iCnt AS INT. would no longer compile when using the compiler’s strict mode.
(2) Disallow the use of abbreviations for database objects. For example, the compiler would no longer allow a program to use the shortest unique identifier for a field in a table.
(3) Require all database references to be fully qualified, database.table.field.
(4) Identify all unreferenced variables and properties.
(5) Identify any code section which cannot be executed.
(6) Identify if a user-defined function or non-void method does not contain a RETURN statement.
Do you expect the Compiler to perform code path analysis and therefore confirm that ALL code paths have a RETURN statement?
(7) Other scenarios?
For whatever set of tests we conclude constituting strict mode compilation, do you want the ability to choose the specific set of tests you want the compiler to enforce?
Do you want a ‘enforce all’ option?
If we added additional checks in future releases would it be acceptable if the ‘enforce all’ executed more choices in a future release?
Any other thoughts you have on this change are greatly appreciated.
Thanks
Evan BleicherStop receiving emails on this subject.Flag this post as spam/abuse.
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com[/collapse]
Reply by Thomas Mercer-HurshMike, I think you raise a couple of important points. One is that one would not want this to make development awkward. The other is that one might want the option for the whole think to be a warning or fatal. Perhaps each option could be 0, 1, or 2 for Ignore, Warning, Error?
Stop receiving emails on this subject.Flag this post as spam/abuse.
Now, now, Tom, your last two are going a bit beyond the intent ...
Reply by Thomas Mercer-HurshNow, now, Tom, your last two are going a bit beyond the intent ...
Stop receiving emails on this subject.Flag this post as spam/abuse.
My eyes!!!! I'm blind!!!! Arggggg!!!!
I would say: make a compiler option which let's you specify a file which contains the options you want to be strict on (JSON PLEASE). You'll never get consensus on what to put in and what to leave out. If strict mode would force #3, I would not use it at all, for example.
Thank you all for your energetic and quick input on this topic. I will assert that we will not move forward with #3. The development team will need to design an extensible capability and your input on this topic has been very helpful.
I like the idea of all of it except for #3.
Our web-broker/web-agents are linked to 3 databases in total (main, pse, and an images one), and while yes under this scenario it does mean all 3 have the same system tables, they never have the same user tables.
One idea for #3 is if you could change it on a per-user basis. Some people might like it being 'database.table.field', I personally would prefer 'table.field', while others may not want it at all.
I know i've been burned a few times in our application where a previous developer chose not to reference everything by 'table.field' and then I've gone in and added a temp-table to that particular .p file (or maybe to a .i file that is referenced by the .p file), then gone to compile it and had to go through the file and fix up every error that pops up where it can't determine whether it should be the database table or temp-table.
One thing though, I'm not really sure 'strict' is going to benefit me in anyway except on the live system anyway, since in development I use AppBuilder in remote-editing/remote-compiling mode.
[quote user="Evan Bleicher"]
For whatever set of tests we conclude constituting strict mode compilation, do you want the ability to choose the specific set of tests you want the compiler to enforce? Do you want a ‘enforce all’ option? If we added additional checks in future releases would it be acceptable if the ‘enforce all’ executed more choices in a future release?
[/quote]
The bolded part is an absolute requirement - that's not an option.
I'd also suggest either
so compile strictness can be controlled on a per-file basis.
Evan, great initiative... with all those ideas floating around guess will end-up a mix between compiler and tooling features.
For me 'strict' means more something like 'all warnings are errors' but then we need to spot the warnings that have the most potential to be actual errors. What I would like to see implemented is more the 'compliance level' so if I need to make sure the code will compile in V9 just set that in project settings... that will ease the pain for some of the ISV's out there.
Ah, strict should flag as error all usage of deprecated keywords (tooling support so we can use @deprecated annotation in frameworks will be a nice addition), if you can find possible leaks on memptr/handles (com, sax, sockets) would be great.
And while you're at it... something I've loved from Larry's talk about perl 6, aim for awesome error messages :)
Guess those are the kind of messages that points to a solution instead of just the error, check-out user reports on 'less than awesome error message'.
... so if I need to make sure the code will compile in V9 just set that in project settings... that will ease the pain for some of the ISV's out there.
Ah, strict should flag as error all usage of deprecated keywords (tooling support so we can use @deprecated annotation in frameworks will be a nice addition), if you can find possible leaks on memptr/handles (com, sax, sockets) would be great.
And while you're at it... something I've loved from Larry's talk about perl 6, aim for awesome error messages :)
Guess those are the kind of messages that points to a solution instead of just the error, check-out user reports on 'less than awesome error message'.
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com[/collapse]
Over many years and many Info Exchanges, the OpenEdge community has requested improvements to the ABL Compiler. Product Management has requested that Development evaluate the addition of a “strict” option to the COMPILE statement. I would like to solicit
your input on this improvement.
I will assert that the “strict” mode on the compiler would instruct the compiler to generate an error if any of the set of conditions is encountered. So, which specific actions would you want to see in a COMPILE “strict” mode? Several actions for your consideration:
(1) Disallow the use of abbreviations for all ABL keywords. For example: DEF VAR iCnt AS INT.
would no longer compile when using the compiler’s strict mode.
(2) Disallow the use of abbreviations for database objects. For example, the compiler would no longer allow a program to use the shortest unique identifier for a field in a table.
(3) Require all database references to be fully qualified, database.table.field.
(4) Identify all unreferenced variables and properties.
(5) Identify any code section which cannot be executed.
(6) Identify if a user-defined function or non-void method does not contain a RETURN statement. Do you expect the Compiler to perform code path analysis and therefore confirm that ALL code paths have a RETURN statement?
(7) Other scenarios?
For whatever set of tests we conclude constituting strict mode compilation, do you want the ability to choose the specific set of tests you want the compiler to enforce? Do you want a ‘enforce all’ option? If we added additional checks in future releases would
it be acceptable if the ‘enforce all’ executed more choices in a future release?
Any other thoughts you have on this change are greatly appreciated.
Thanks
Evan Bleicher
Flag this post as spam/abuse.
Not just overkill, but positively not wanted!
How about adding a new ABL statement to each source file, detailing what features should be strict or not, in that particular file, rather than having to specify it in the COMPILE statement. That way you know that each file will always be compiled with the specific settings relevant for that file. When specifiying the settings in the COMPILE statement, you can count on people making mistakes and mixing files up, or forgetting to specify them. What language features are expected in the souce code is a setting that belongs in that source code. Just like e.g HTML pages specify which version of HTML they use.
The COMPILE statement could still have the possibility to specify some checks, but only meant for those source files that don't yet contain their own setting for this. The COMPILE statement could also still have a setting for exactly how severely you want it to treat transgressions to the currently requested feature settings.
The settings in each file might also include a setting for which version of ABL is being used, in stead of the "keyword forget" startup option and other compatibility options.
A project setting might insert a default for this settings statement in each newly created file. Or just control default settings to the COMPILE statement for those files that don't have their own settings.
Having a setting for the ABL version (or settings for specific language features), it might even become possible to introduce non-backwards compatible changes to new versions of ABL, without breaking old source code. If the old source code is already marked with the version it was written for, it could still conform to the old interpratation of the code, and not change until this setting is explicitly updated in that file.
I can't see having to modify every source file to add specifications, especially since the specifications will normally be a shop standard and thus should apply universally. As noted, I can see the option for ignore, warning, or error on any given standard so that a shop can, for example, decide that they are going to fix a particular thing when they have the time, but want to be able to ignore it if they are in a hurry. I can, however, see a role for annotations so that one can mark lines as exceptions to be preserved without error.
I can't see having to modify every source file to add specifications, especially since the specifications will normally be a shop standard and thus should apply universally. As noted, I can see the option for ignore, warning, or error on any given standard so that a shop can, for example, decide that they are going to fix a particular thing when they have the time, but want to be able to ignore it if they are in a hurry. I can, however, see a role for annotations so that one can mark lines as exceptions to be preserved without error.
Flag this post as spam/abuse.
This is getting shocking! :)
If you have a default, you only need to mark the files that are exceptions.
Remember also that each "shop" may not want to enforce every possible check in their shop standard (we heard many different responses to who wanted which features), so all other settings may still be up for individual choice in each file. I'm also thinking we could extend this to many other settings than just checking "strict" language standards, and some of these would perhaps not be included in a shop standard, but in stead vary between files depending on their needs. And even if you have shop standards, you may still often import a couple of files from other sources, which use their own standard, so you may still want to be able to specify this on a finer level than just one single shop standard globally for all files.
And my thinking was also that you could use this for instance when migrating from using one ABL feature set to other incompatible ones (in the future, for instance changing which kinds of names should be matched first, and other things that have been kept in ABL over the years just for backwards compatibility, which this would finally give us a way to change to more moderns needs without breaking old code), and then you would activate this feature in only the files you have migrated so far, and not in other files that have not yet been migrated (or don't need migrating at all, since you can just leave them using their old feature set). Or even, just when "migrating" into using strict settings, you could have great use of being able to mark which files have already been adapted to work with these strict settings, and which have not yet been adapted and will fail when compiled that way...
Exceptions are what I want the annotations for ... like ProLint where one can annotate that a particular standard violation should not be reported for the following line.
To be sure, I can see having one standard to compile for production and another standard for compile for development, the latter being strict for anything that one is going to touch and the former being loose because there is a bunch of stuff in existing code which one is not ready to clean up yet.
But, it does seem to me that the whole point is to establish a shop standard ... not a hodge-podge file by file whimsey. If one is "too busy" to make everything right, the select the option to generate warnings instead of errors and just ignore them.
BTW, Evan, I would welcome a parallel thread on improvements to make in COMPILE LIST and XREF!
Exceptions are what I want the annotations for ... like ProLint where one can annotate that a particular standard violation should not be reported for the following line.
To be sure, I can see having one standard to compile for production and another standard for compile for development, the latter being strict for anything that one is going to touch and the former being loose because there is a bunch of stuff in existing code which one is not ready to clean up yet.
But, it does seem to me that the whole point is to establish a shop standard ... not a hodge-podge file by file whimsey. If one is "too busy" to make everything right, the select the option to generate warnings instead of errors and just ignore them.
BTW, Evan, I would welcome a parallel thread on improvements to make in COMPILE LIST and XREF!
Flag this post as spam/abuse.
Reply by Mike FechnerAnother optional rule set: UNIX compatibility of source.
- forward slashes only for run statements and include file references
- exact casing for class names, include file references and I'd the compiler has a chance to test this also run statements.
- no .NET class access for some files (AppServer code)
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com[/collapse]
It seems like none of us agree completely, so I would say the best approach is to make each of those items individually selectable. And some items should be furhter refinable as warnings -vs- errors.
I would NEVER want #1. I tell my customers I'm paid to think, not to type :-)
#2 is my favorite, but obviously might break a lot of legacy code.
#3 sounds bad.
#4-5 should be warnings
#6, to be honest i don't understand the ramifications.
@Tom -- I would propose a switch that automatically converts UPPER CASE keywords to lower case at the same time it chopped off the meaningless INE ARIABLE and HARACTER fragments :-) I think there's a market for a configurable editor here.
Garry Hall created the XREF forum thread. It can be found here: community.progress.com/.../16757.aspx
First off, the implementation.
I would prefer that these be set
The pattern I have in mind is similar to what we have with LOG-MANAGER:LOG-ENTRY-TYPES.
Examples:
-compilerOptions "DatabaseObjectAbbreviation:2,Deprecated:1,MissingReturn:2"
COMPILER:OPTIONS = "UnusedVariables:2"
It would be handy to have a method to append/update the list, e.g. in a session with
-compileOptions "EnableAll:3"
COMPILER:SET-OPTIONS("UnreachableCode:1,UnusedVariables:0")
Will update the entry for UnreachableCode to be a warning only and remove the Unused variables option.
1. Abbreviated keywords: Bad style that does not introduce significant risk. Eclipse editor keyword expansion is sufficient.
2. Abbreviated database objects: Yes, please! Kill this ticking time bomb!
3. Fully qualified database references: NO! This introduces more work with no gain. The compile fail in any case if there is ambiguity.
4. Identify unreferenced variables and properties: Variables - YES, Properties? NO! How will you know? The object may be a complex data container used to pass as parameter.... Unless the SET (or GET) is PRIVATE with no initial value.
5. Identify unreachable code: The compiler does this already...
6. Methods and functions without a RETURN: Yes, by nature all code paths should return something, unless an error is thrown, of course.
7. Other:
8 More Other
Two header keywords, with similar rules to BLOCK-LEVEL, ROUTINE-LEVEL and USING (e.g. at the top of t he file before any other statement):
OS-PORTABLE.
Compiler will only accept "~" as the escape character. Use of "\" (but not "~\"), .Net classes, EXTERNAL routines (*.dll or *.so) causes a compile error, unless the statement is annotated with @OSSafe(), for cases where the programmer handles OS-specific items, e.g.
@OSSafe(TRUE).
IF OPSYS="UNIX"
THEN OS-COMMAND ~~/scripts/doInterface.sh.
ELSE OS-COMMAND VALUE(OS-GET-ENV("HOME") + "\batfiles\DoInterface.bat").
@OSSafe(FALSE).
UI-PORTABLE.
The compiler gives an error if the code contains any visual element, e.g. a frame, that is not portable across the UI. Special consideration is needed where output is opened to a stream (the STREM-IO frame option will most likely be key) since it should be possible to run the following regardless of the UI environment used to compile:
vFile = SESSION:TEMP-DIRECTORY + "/" + GUID.
OUTPUT TO VALUE(vFile):
FOR EACH Customer WITH STREAM-IO:
DISPLAY Customer.CustNum
Customer.Name
Customer.TelNo.
END.
OUTPUT CLOSE.
Finally
Mike already agreed with the Doctor twice in this thread. I fear that if it happens again, heaven will fall and we will all be walking around with blue caps!
First off, the implementation.
I would prefer that these be set
The pattern I have in mind is similar to what we have with LOG-MANAGER:LOG-ENTRY-TYPES.
Examples:
-compilerOptions "DatabaseObjectAbbreviation:2,Deprecated:1,MissingReturn:2"
COMPILER:OPTIONS = "UnusedVariables:2"
It would be handy to have a method to append/update the list, e.g. in a session with
-compileOptions "EnableAll:3"
COMPILER:SET-OPTIONS("UnreachableCode:1,UnusedVariables:0")
Will update the entry for UnreachableCode to be a warning only and remove the Unused variables option.
1. Abbreviated keywords: Bad style that does not introduce significant risk. Eclipse editor keyword expansion is sufficient.
2. Abbreviated database objects: Yes, please! Kill this ticking time bomb!
3. Fully qualified database references: NO! This introduces more work with no gain. The compile fail in any case if there is ambiguity.
4. Identify unreferenced variables and properties: Variables - YES, Properties? NO! How will you know? The object may be a complex data container used to pass as parameter.... Unless the SET (or GET) is PRIVATE with no initial value.
5. Identify unreachable code: The compiler does this already...
6. Methods and functions without a RETURN: Yes, by nature all code paths should return something, unless an error is thrown, of course.
7. Other:
8 More Other
Two header keywords, with similar rules to BLOCK-LEVEL, ROUTINE-LEVEL and USING (e.g. at the top of t he file before any other statement):
OS-PORTABLE.
Compiler will only accept "~" as the escape character. Use of "\" (but not "~\"), .Net classes, EXTERNAL routines (*.dll or *.so) causes a compile error, unless the statement is annotated with @OSSafe(), for cases where the programmer handles OS-specific items, e.g.
@OSSafe(TRUE).
IF OPSYS="UNIX"
THEN OS-COMMAND ~~/scripts/doInterface.sh.
ELSE OS-COMMAND VALUE(OS-GET-ENV("HOME") + "\batfiles\DoInterface.bat").
@OSSafe(FALSE).
UI-PORTABLE.
The compiler gives an error if the code contains any visual element, e.g. a frame, that is not portable across the UI. Special consideration is needed where output is opened to a stream (the STREM-IO frame option will most likely be key) since it should be possible to run the following regardless of the UI environment used to compile:
vFile = SESSION:TEMP-DIRECTORY + "/" + GUID.
OUTPUT TO VALUE(vFile):
FOR EACH Customer WITH STREAM-IO:
DISPLAY Customer.CustNum
Customer.Name
Customer.TelNo.
END.
OUTPUT CLOSE.
Finally
Mike already agreed with the Doctor twice in this thread. I fear that if it happens again, heaven will fall and we will all be walking around with blue caps!
Flag this post as spam/abuse.
These are the most important options from my point of view:
2. Abbreviated database objects
7. Other:
Warning if a database buffer read with no explicit lock option will result in a SHARE-LOCK
Warning if a buffer's lock will downgrade to a SHARE-LOCK at the end of a transaction.
Nice list Simon!
While it is fun to joke about Mike and I agreeing, it is, of course, the case that we can only disagree as strongly on some points as we do, because we agree about so much else. If there is real, universal disagreement, there is nothing to talk about.
We still use NO-ERROR and have problems with following situations:
1. Compile warning if no check of ERROR-STATUS after statement with NO-ERROR (Possible with list of statements where this would be allowed, fx FIND)
2. Compile error if ERROR-STATUS check without preceding statement with NO-ERROR
Hello,
I just have been noticed about this old topic. Very interesting idea, I am just surprised that almost no one wants #3. This, together with #2, is what I like most from that list - except that with option to enforce just table.field, not database.table.field.
Now, why I need it:
- when table name is not specified you will get stupid errors when someone will add a variable with the name equal to DB field later.
- if you have a lot of tables with the same field name compilation of the source without table name takes quite a long of time. We have cases when compilation of single line takes over 10 seconds.
Regards,
Piotr
Hello,
STRICT mode should just disable all the compiler "auto insertion" like:
1.
{include-name.i "parameter}
-> Compile error missing "
2. functions without parenthesis,
FUNCTION myname RETURNS char:
-> Compile error missing ()
3. Autoclosing opened blocks at the end of a file -> Compile error missing END
Other stuff:
1. No proper end statement
2. missing return statement
3. keyword abbreviation
4. field use without table name
5. unused variables
6. unused parameters
7. linux/windows path checking
8. CaseSensitive would be great for functions, methods, variables etc.
9. Duplicate variable name (global and local variables in a block)
I as well have been notified of this thread so Piotr, you are not alone :)
But I agree on the generic opinion in this thread about #3. In the past it has given me more trouble than relief so I would definitely not use it. Even stronger: when I refactor a source that contains database references, I strip them. We are working in an environment that formerly had several databases. Over time, we have merged some of the smaller ones into one custom database. It is /so/ convenient that you just have to recompile the sources and not have to alter them all to change the database, or have to create an alias.
I like the idea of having this as general settings for the client, possibly set at high level in DevStudio, with the possibility to override on project level and even on source level. The latter could very well be done with annotations.
It would also be great to have a setting that warns for the unuseful usage of the keywork RELEASE. In our code it seems like nobody understands a ^#$ from buffer scoping (not a surprise if you never use named buffers) so it is RELEASE statements all over the place.
A good option would be to have an option to set a limited scope for buffers. If you refer to an unnamed buffer in an internal procedure, it automatically scopes to the whole .p. This should really be only to the enclosing internal procedure / function.
On top of Lars comment about "Autoclosing opened blocks at the end of a file -> Compile error missing END", I've found this code recently :
define public property Height as int
get ():
return 0.
end set. /* Should be end get */
Was surprised to see that it compiles without any problem, but still something which shouldn't be accepted by the compiler.
That I think is a bug so you should report it to technical support.
I can almost feel Gilles pain, the language is way to ambiguous and things won't probably get better as backward compatibility reigns :(
If any of those ever gets implemented I would really like the 'use strict' annotation at file level much as in javascript... something that is ignored by previous versions and used to switch the compiler in strict mode what a file with that annotation is compiled. That way one can 'catch-up' in time, a compiler flag to compile the whole codebase will probably just make too many nervous :)
As for warnings those have little to do with strict mode, even more if someone has an option to decide what to be ignored... this can well be added in the tooling (psdoe) and can be displayed as warnings even if not in strict mode (unless the developer/team choose to ignore particular warnings for reasons that they know better).
However, if 'use strict' annotation is set in a file there should be no option to fake that by 'cherry picking' the rules... is that too much for one, just remove the annotation and keep that on the todo list for later :)
Bref, the error conditions for strict mode might not be that long and have nothing to do with code formatting/case used for keywords, abbreviations and other things that might be nice to be reported as 'code style warnings'... there is still room for a 'lint' tool to help with those kind of things.