Our current rule in place: all file names lower-cased.
This rule meets Progress portability guideline: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/wp-codeport/case-sensitivity.html
However more and more developers are complaining about the readability impact:
thisproceduredoesthis.p vs. ThisProcedureDoesThis.p
*If* we would change our rule: file names should UpperCamelCased. What are the possible pitfalls?
In other words, what do we need to pro-actively check/test to avoid issues at runtime. Taking into account that most server code runs on a case-sensitive linux os.
Can this be summarized in a step by step checklist?
How can these checks/tests be automated? To catch all mistakes overlooked by a developer before deploy.
Personally I hate filenames to be in anything other than lowercase (classes excluded). And one pittfall: is it getFilename.p or getFileName.p...?
@bronco your pitfall I try to cover it by introducing the words, "UpperCamelCasing" and "lowerCamelCasing".
At this time the proposal is to lower-case all file names except for classes which should be in UpperCamelCase. But not all developers like the the proposal... hence my question to get a full understanding of the impact.
Bronco's point is that both "file name" and "filename" are words - so depending on which you consider right determines if the N should be capitalized.
We do not use casing in file names.
Procedures are UpperCamelCase.
Functions are lowerCamelCase - if the function is external, the first word is the namespace (file name / filename of the external) otherwise the verb - get / set / calculate etc
Auuwch I overlooked bronco's point, in my head I read the difference of the first case.
About the howto camel case correctly, I documented it like this: drive.google.com/.../view
And my reference for this was: google.github.io/.../javaguide.html
Personally I'm in favour of:
- directory names lowercase (also namespaces)
- .p, .w, .i filenames in lowercase
- classes UpperCamel (and therefor also the .cls files)
- outward facing members (public/protected) UpperCamel
- private and local lowerCamel
- buffers are prefixed with b- (make it easier to determine scope imho)
- no prefixes (with exeption for Interfaces)
However, I work with TypeScript more and more and that is more lowerCamel for members (but filename strictly in lowercase).
I do realize we're on the brink of a holy war with this :-)
@bronco .p, .w and .i, all your lowercase filenames, do you use any other word divider char like '-' or '_'?
Normally I don't use either _ or -. If I have to choose I would pick - (dash).
Having said that, Angular 2 has a convention where a component name is for example HomepageComponent and file the component is in, is homepage-component.ts. In other words: The uppercase character results in a - (dash) and then the lowercase of that character.
As long as you operate on a Windows machine, this will be no problem since Windows does not differentiate between upper and lower. The problem starts when running things on unix-like machines. We have adopted the lower-all rule. It's ugly, but at least it works.
Workaround could be to use an include file (yuck) for the run statements in which you do a LC of the file name to run. That way, you can store them on disk in all lower, but call them in all camel cased variations you like.