naming-convention / naming-convention-guides Goto Github PK

Hi guys,

I was thinking to contribute to the Git naming conventions. In the majority of my projects I've use this model (https://nvie.com/posts/a-successful-git-branching-model/) . This branching model encourage certain naming conventions. I am aware that every developer in the community reshapes this model to his own workflow and needs. But I think worth to described the guideline as it was described in first place.

For me this is not a standard, it is just a well know naming convention guideline and I am not sure what is the best way to organice this in the guideline.

If you guys want to integrate cases like this, I would say to add one section to the main Git section with the name Known models or Common cases where we can explain in there which naming conventions this case encourage (keeping the same format as the main README).

What do you think?

C# constants should be all caps because, constants being all caps is a recognized convention across multiple languages, python, ruby, java and php, for visual identification, C# consts convention should also be all caps, what do you think ? (if you want me to do it and create a pull request, let me know) , oh and i noticed that, for C# there exist a constant naming convention, its under the enum_naming.md file, (there is a PR waiting to be merged for this)

In the page commit-message-naming.md it says that the body of a commit message should not exceed 72 characters. In the example right after, the body of the commit is a 101 characters long for the first line and 110 for the second.

File: Readme.md (master / dev branch)
Links for https://github.com/naming-convention/naming-convention-guides#naming-convention-topic-list are broken.

Maybe you should use:
/tree/master/
instead of /blob/

The given examples for naming conventions conveniently avoid the hottest debates. In fact, very few style guides I've found even address this question

Relevant style guides

Other variables to consider

• "Shoot Laser Beam" (once upon a time "laser" was an acronym and it's now become a word)
• "GUI Generator" (gui might be considered sorta "in-between". I think it's slowly transitioning to a word)
• "ID Parser" (ID isn't an acronym but an abbreviation)
• "System.IO" (two-letter acronyms like "IO" are particularly contested and Microsoft even has specific rules for them)
• XMLHttpRequest (an actual web standard name, smh. What's to be done when you have two acronyms right next to each other?)

Add JavaScript as a topic

We are currently missing the whole topic for JavaScript naming conventions.

Acceptance Criteria:

• Add at least 5 different topics for JavaScript naming conventions.
• Add a home page for JavaScript naming conventions and list all the covered section.
• Make sure nothing is copied from internet. All the examples and descriptions should be original, otherwise we get penalized by Google for a copied content.

If it is the first time that you contribute to NamingConvention.org, follow these steps: (you need to have make and yarn available on your machine)

1. Write a comment there to let other possible contributors know that you are working on this bug.
2. Fork the repo
3. Run git clone https://github.com/<YOUR_USERNAME>/naming-convention.git && cd babel
4. Run yarn && make bootstrap
5. Wait ⏳
6. Run make watch (or make build whenever you change a file)
7. Add a test if needed (only input.js; output.js will be automatically generated)
8. Update the code!
9. yarn jest babel-preset-env to run the tests
   Since you don't need to write new tests, you can run OVERWRITE=true yarn jest babel-preset-env and they will be automatically updated.
10. If it is working, run make test to run all the tests
11. Run git push and open a PR!

I asked a question on gitter/matrix and although multiple users are in the channel there is no response from anyone. Looking at this repository I'm starting to think it's been abandoned.

Anybody still around?

Hungrian notation should be added to the list of notations in the docs/lexicon page.

Hungarian notation resembles "camelCase" and "PascalCase" with the exception that it has a prefix that denotes some additional semantic meaning (usually data type). For example:

• pContractor is a pointer that points to a Contractor object.
• bEmployed is a boolean representing whether someone is employed or not.
• fHourlyPayRate is a float representing the amount a contractor is paid per hour.

Hungarian notation can be extended to include the scope that the variable exists within. For example:

• m_iDaysWorked represents the number of days someone has worked for, that is stored as an integer and whose value is a member (meaning: is independent for each instance) of a class, in this case of contractor.
• s_iNumberOfOpenContractorPositions represents the total number of contractor positions available, stored as an integer. Since this value would be the same for all instances of the contractor class, it is declared and assigned statically on the contractor class itself.

More info: https://en.wikipedia.org/wiki/Hungarian_notation.

Personal note: While hungarian notation is falling out of use thanks to more modern development environments and tooling, it is still prevelent in many older and/or larger projects. It is also worth being aware about to prevent confusion among developers from different backgrounds. For instance:

Programmer A creates a variable called iHaveCompletedCourse, and commits the code to a project. Some time later, Programmer B tries to use or updates the variable iHaveCompletedCourse and ends up encountering errors. Now they have to spend time trying to determine why a variable they think is an integer, is not accepting an integer value when in fact it was a boolean and the "i" is in fact refering to whether the user themselves have completed a course or not.

The link linking to the page 'Constant Naming' in the README.md file leads to a 404, while the file constant-naming.md works fine.

Currently when users land on the home page, if they click on one of the item in the topic list, after navigating to a policy in a certain topic, the user will be redirected to a wrong URL.