Propose a new filename scheme for all pattern files

[ash-teach]

Assess existing filenames and determine if an alternative approach is preferred. Discuss here before implementation.

[kattsky]

Hi @ash-teach I'd like to help with this too

[nazrinzuwair]

Hello @ ash-teach, Can I be assigned to this?

[mrsaif888]

hello @ash-teach can you assign me this?

[ash-teach]

@kattsky, @nazrinzuwair and @mrsaif888 I think you can all work on this together? Feel free to put some proposals together in comments here and that will allow others to weigh in on your ideas.

[KaiKitKobold]

I think this issue Is less of a sole Document issue (Although a Document or rules could be defined in the read.me, at a later date/version. Either way, before everyone rushes to get assigned to this issue, we will discuss the implementation of the result.

Looking at more extensive pattern libraries such as Design Patterns Library and Java Design Patterns, I've noticed a pattern of rather short descriptive Titles such as Builder.js, AppTest.java, etc.

Since the Folders and the Table of Contents links (Will update if requested) do most of the heavy lifting in the project. Short Simple File names such as singletonJavaScript.js can work; however, to add to the ease of accessibility, I recommend we use underScores (With no actual rules on definitive camel case of the languages) Such as Singleton_JavaScript.js instead; of course, we should also do singleton_JavaScript.js, I wish to hear everyone preference on that scheme.

[kattsky]

I've done some research and this is what I've gathered.

To provide information at a quick glance,

• File names will have 3-4 elements
• As a general rule, maintain a 40-50 character limit. But for brevity, we can go for 30 characters or less.
• Use 3-4 elements: prefixlanguage used design pattern _ author.file extension
• Use underscore for element delimiters
• Use camelCase for word delimiters except for prefix
• Use a prefix for implementation discussion like impl_ in documentation OR
• With the current READMEs in subdirectories, it can be README lua singleton _kcor.md
• Use usecase_ for files focusing on specific use cases
• Use snippet_ for code snippets of the design pattern

Documentation: For example: prefixlanguage used design pattern _ author.file extension The author info can be shortened to only show first name initial followed by first 3 letters of their last name

File name: impl_js_observer_kcor.md OR README lua singleton _kcor.md

Code: Prefixes: usecase_ or snippet_ File name: usecase_kotlin_observer_kcor.kt OR snippet_js_observer_kcor.js

And...

• If we need to track versions: Use version number _v01, _v02, and so on to track file versions Or Use version date with ISO 8601 format YYYYMMDDhhmm or YYYY-MM-DD, with 24-hr military time

Also once we have an agreement on the file naming convention, I can help add it to our README file so that others can follow the standard.

References: Barsky, B. H. P. L. E. (n.d.). File naming. Research Data Management. https://ubc-library-rc.github.io/rdm/content/01_file_naming.html

File naming conventions. (n.d.). Data Management. https://datamanagement.hms.harvard.edu/plan-design/file-naming-conventions

OSF. (n.d.). https://osf.io/dpu45

[kattsky]

Just a thought, while not a file name convention, what do you think about adding a file header comment to include the following:

• Author
• Design Pattern
• date last modified
• date of the initial version of the file

Having the file header will shorten the file name as it won't have the author name in it.

[nazrinzuwair]

Hi,

I completely agree with @kattsky suggestions, and I'd like to add some additional points to address the issues we've identified with the current naming conventions:

1. The current naming conventions in the directory are extremely confusing and result in duplicate names. For instance, in the "Abstract Factory" directory:

├── abstract-factory
  │   ├── abstract-factory

  │   ├── README.md

This directory contains duplicate names for subdirectories ("abstract-factory"). It's advisable to opt for more descriptive names for subdirectories, such as "abstract-factory-implementation".

2. The directory structure under "Behavioral Patterns" appears to be well-organized with subdirectories for each programming language. However, the "Observal" directory should be renamed to "Observer" for consistency.

├── behavioral-patterns
  │   ├── Observal
  │   │   ├── Dart
  │   │   │   ├── observer
  │   │   │   ├── README

3. Moreover, there's inconsistency in the naming conventions of directories throughout the project. Some directories use underscores (_) to separate words, while others use hyphens (-). For instance:

├── basic_dart_singleton
│   │   │   ├── lazy_dart_singleton

├── abstract-factory

While both naming styles are valid, hyphen-separated naming (kebab-case) is more commonly used in file and directory names due to its compatibility with most file systems and web conventions. Therefore, I recommend utilizing hyphen-separated naming (kebab-case) for file names to ensure compatibility, readability, and consistency.

Implementing the suggestions provided by @kattsky will greatly improve the clarity and understandability of our file names.

Thank you.

[ting-dev-coder]

I am up for @KaiKitKobold's suggestion. A file name should be descriptive and as short as necessary. The author and date last modified could be included in the document, but the date of the initial version of the file is probably not necessary.

[john24alex]

I like the @nazrinzuwair suggestion about naming and directories because is intuitive to navigate. Is just to have clear the rules in the contributing file before submitting a PR. so the first step is to read and understand the contributing before starting work on an issue

[mrsaif888]

@kattsky @nazrinzuwair i agree with you both i can add one thing to contribute in this like using prefixes like "usecase" for files focusing on specific use cases and "snippet" for code snippets for example we have a use case focusing on implementing the Observer design pattern in Java. The file name could be (usecase_java_observer_kcor.java)