Hi Chen, > That's the main reason I always correct inline IF() to be IIF(). > > Of course, but part of the reasons to use hbformat is to deal with old ugly > code like that. > At the moment hbformat just interpret it as an IF statement and might fail > many lines > away on a mismatch END or other statement > (had to choop a large PRG quite a few times to find the offending line)
I'm not sure hbformat is the best place to deal with these, since it would make its code very complicated and it will never give perfect results for all cases. I was proposing extra Harbour compiler warnings for this purpose a while ago. For the compiler it's a much easier job to detect these cases and show a warning, since the full PP + parser logic is there. All such warnings of course should be either explicitly enabled, or easily disabled by switches to not cause problems for those who don't care. But they would be enabled for Harbour core code. Some candidates for such problematic syntaxes: - 'IF()' [ better alternative: 'IIF()' ] - '=' operator (this would also need a pseudo-function alternative for non-exact equality) [ better alternative: ':=' or '==' ] - '&&' comment [ better alternative: '//' ] - '*' comment [ better alternative: '//' ] - Multiple ANNOUNCE (where additional ones are now silently ignored) Some very old style code (not problematic per se, but they have superior alternatives, so they just synonyms which make code less readable): - '#' operator [ better alternative: != ] - '.not.' operator [ better alternative: ! ] - 'END' statement [ better alternative: 'END<x>' ] Avoiding these old constructs may give the way to extend the language into new directions, and for sure result in more easily readable code for both machines and humans. ] Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
