Pitfalls for CamelCasing file names? - Forum - OpenEdge Development - Progress Community

Pitfalls for CamelCasing file names?


Pitfalls for CamelCasing file names?

This question is not answered

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?

  1. The source file name is the truth.
  2. Make sure old lower-cased r-code is deleted.
  3. All code references should use the exact same cased name
  4. ...

How can these checks/tests be automated? To catch all mistakes overlooked by a developer before deploy.

All Replies
  • 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.