inclowercase
Compile will fail on Unix, use only lower-case includefiles
Rule "inclowercase" will raise this warning when it finds an include directive that has uppercase characters. For example:
{subdirectory/IncludeFile.i}
The reason for this warning is that this sourcefile will not compile on Unix. Change the name to all lowercase so the source can be compiled on Unix and on Windows.
The assumption is of course, that sourcefiles are FTP'd to Unix with the "lowercase name conversion" option set in the FTP program.
Compiled r-code used to be platform indepedent: you could develop on Windows, compile on Windows and simply FTP the r-code to Unix and it would just run fine (even though Progress did not actually guarantee that).
But this breaks if you develop on 32-bit Windows and deploy to 64-bit Unix: you just have to compile on the target platform to get working r-code. This rule helps to locate include directives that won't compile on Unix in your new and existing code.
- Printer-friendly version
- Login to post comments
Comments
Why?
The assumption is of course, that sourcefiles are FTP'd to Unix with the "lowercase name conversion" option set in the FTP program.
Why would you make that assumption? I, for one, have been moving to mixed case file names. Sure, I realize that Windows would not be able to handle myFileName.p and MyFileName.p in the same directory, but what idiot would even try to use such a naming convention?
Because
Why would you make that assumption? I, for one, have been moving to mixed case file names.
One system is case-sensitive, the other is not. That's a risc. To make it work on both systems you have to be consistent that the search specification is identical to the actual filename. Being consistent is difficult but gets easier when you pick a naming convention and stick to it. I suppose any naming convention is ok as long as it can be prescribed and enforced and I think that a simple naming convention works better than a more complicated one. "only use lowercase" is simple and can be automated, it is the convention that we use at the company where I work.
So maybe this could be a company-specific rule, but I publish it anyway.
Back to 8+3?
And do you still stick to 8+3 file names? Good convention for the time and it minimizes typing, but I don't think it is a convention I would want to stick to going forward.
Yes, to be sure, sticking to lower case means that you can't make a mistake in case, but there are many other kinds of mistakes one can still make. It just seems unlikely to me that, if one is using a convention like CustomerBE.cls or CustomerDA.cls that one is likely to make case errors since the camelcase here is more conspicuous than spelling, like CustomorBE.cls.
It seems to me that the real danger here is in getting the file name wrong on a case-sensitive operating system and that is easily avoided by not using things like a force lower on FTP.
re: Back to 8+3
I don't understand why you want to know if I stick to 8+3? FYI, no, but I still avoid spaces in filenames.
Perhaps you don't want to use this rule in Prolint. That's fine, every Prolint rule can be disabled, the Prolint tool can enforce style but the Prolint project avoids style discussions. It has always been that way, because there will never be general consensus.
Existing rules (like this one) can inspire someone to make their own, and hopefully submit them back to the project.
For example, this rule may raise the question: can you also make a different rule that checks if case in the include directive is identical to case in the physical file? The answer would be yes.
Sounds like a good rule
Another one would be checking the class name matched the file.