Skip to content

docs: Let's clarify bracket types naming#5915

Draft
keradus wants to merge 5 commits intoPHP-CS-Fixer:masterfrom
keradus:3.0_brackets
Draft

docs: Let's clarify bracket types naming#5915
keradus wants to merge 5 commits intoPHP-CS-Fixer:masterfrom
keradus:3.0_brackets

Conversation

@keradus
Copy link
Copy Markdown
Member

@keradus keradus commented Aug 28, 2021

if we decide to go that path, we need to update some namings too, eg new_with_braces

Nomenclature
============

Brackets
Copy link
Copy Markdown
Member Author

@keradus keradus Aug 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense for you, @localheinz @julienfalque @kubawerlos @SpacePossum ?
i see that sometimes we mix braces/brackets/parentheses, maybe it's worth to unify?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keradus

I am for consistent naming, even if that requires renaming fixers and options!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to rename (deprecate existing + introduce proxy) every fixer that uses old nomenclature within this PR, or maybe only discuss and prepare a list of fixers and options to rename, and create an issue or milestone for that?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kubawerlos
kubawerlos previously approved these changes Aug 28, 2021
@coveralls
Copy link
Copy Markdown

coveralls commented Aug 28, 2021

Coverage Status

Coverage remained the same at 92.283% when pulling e94f14a on keradus:3.0_brackets into ca8aea7 on FriendsOfPHP:3.0.

@kubawerlos
Copy link
Copy Markdown
Member

@keradus
Copy link
Copy Markdown
Member Author

keradus commented Aug 29, 2021

not sure if I would like to use it with git grep. I would rather suggest to generalize ProjectCodeTest::testThereIsNoPregFunctionUsedDirectly and ProjectCodeTest::testThereIsNoTriggerErrorUsedDirectly and provide different sequences (vide Tokens::findSequence)

@GrahamCampbell

This comment was marked as outdated.

@keradus

This comment was marked as outdated.

@keradus keradus changed the base branch from 3.0 to master August 29, 2021 19:09
@SpacePossum
Copy link
Copy Markdown
Contributor

My English, and language knowledge in general, is not good enough to know what are the appropriate names for (, { in singular or plural forms, so I don't have a strong preference.

@GPHemsley
Copy link
Copy Markdown

https://en.wikipedia.org/wiki/Bracket covers this topic very thoroughly.

Brackets table from Wikipedia

Note that "bracket" is itself an overloaded term. Depending on region and context, it can refer to ( ), [ ], or all paired characters broadly.

My preference is the following:

Characters Plural Singular
( ) parentheses parenthesis
[ ] square brackets square bracket
{ } curly braces curly brace
< > angle brackets angle bracket

(As an aside, note that the no_spaces_inside_parenthesis rule is thus named incorrectly.)

@jrmajor
Copy link
Copy Markdown
Contributor

jrmajor commented Jan 23, 2022

I like @keradus's initial proposition. It's nice that every bracket type has a single-word name, and it seems consistent to me, as it doesn't mix up terms from the upper and the lower row from the Wikipedia table.

@github-actions

This comment was marked as outdated.

@Wirone Wirone added kind/refactoring status/rebase required PR is outdated and required synchronisation with main branch and removed status/stale labels Jun 7, 2023
@Wirone Wirone added this to the long-term-ideas milestone Sep 27, 2023
@Wirone Wirone linked an issue Sep 27, 2023 that may be closed by this pull request
@Wirone Wirone marked this pull request as draft September 27, 2023 07:54
@coveralls
Copy link
Copy Markdown

Coverage Status

coverage: 94.661%. remained the same when pulling 8146bf7 on keradus:3.0_brackets into f1abe95 on PHP-CS-Fixer:master.

@Wirone Wirone changed the title Docs: Let's clarify bracket types naming docs: Let's clarify bracket types naming Sep 27, 2023
@Wirone Wirone removed the status/rebase required PR is outdated and required synchronisation with main branch label Sep 27, 2023
Nomenclature
============

Brackets
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to rename (deprecate existing + introduce proxy) every fixer that uses old nomenclature within this PR, or maybe only discuss and prepare a list of fixers and options to rename, and create an issue or milestone for that?

Brackets
--------

ref https://en.wikipedia.org/wiki/Bracket
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ref https://en.wikipedia.org/wiki/Bracket
Within the codebase we use consistent naming convention for all type of brackets (`reference <[../src/Fixer/FixerInterface.php](https://en.wikipedia.org/wiki/Bracket)>`_):

+-------------+----------+--------+
| ( ) | [ ] | { } |
+=============+==========+========+
| parentheses | brackets | braces |
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see one problem here: according to the linked reference square brackets [] are called "brackets" in US english, but the project uses British english, where "brackets" is an alias for parentheses (). This seems little inconsistent, but if we treat it as our internal naming convention then it's fine 👍.

PS. is there any reason why we don't cover chevrons <> here?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's even more complicated when I read it again:

There are four primary types of brackets. In British usage they are known as round brackets (or simply brackets), square brackets, curly brackets, and angle brackets; in American usage they are respectively known as parentheses, brackets, braces, and chevrons. There are also various less common symbols considered brackets.

So it seems like we just use American english here on purpose. I am not against it, as I think it's better to use these dedicated names rather than "round|square|curly|angle brackets" for every fixer/option name. I just want to make conscious decision 🙂.

Copy link
Copy Markdown
Member

@Wirone Wirone Sep 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keradus what about custom tokens? Some of them could possibly be renamed just like block types (like CT::T_ARRAY_INDEX_BRACE_[OPEN|CLOSE]), but some are the missing pieces of built-in tokens (like CT::T_CURLY_CLOSE, where T_CURLY_OPEN is a native one), and it would lead to inconsistency 🤔.

And what about token transformers? Should we rename related methods and all the references that use old nomenclature?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Wirone

I wondered myself about renaming token transformers, since they also use and refer to constants from PHP which sometimes have inconsistent naming.

Perhaps it's best to keep them as they are, as they are used internally only?

Copy link
Copy Markdown
Member Author

@keradus keradus Sep 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

either keep them as-is, or have 2 custom tokens that are having same value under the hood.

(CT:: is public interface, custom fixers could use them too)

@localheinz
Copy link
Copy Markdown
Member

localheinz commented Sep 28, 2023

Following @GPHemsle's #5915 (comment) and what I mentioned in #7328, I believe we have the following options:

Option A

Characters Plural Singular
( ) parentheses parenthesis
[ ] square brackets square bracket
{ } curly braces curly brace
< > angle brackets angle bracket

Advantages

  • no room for misunderstanding what means what
  • understood by people familiar and unfamiliar with writing and typography
  • somewhat used in the code base

Disadvantages

  • use of square brackets, curly braces, and angle brackets may be considered as neoplasms (I had to look that term up)

Unclear

  • may or may not require more work for maintainers, contributors, and users than option B for deprecating and proxying fixers and options

Option B

Characters Plural Singular
( ) parentheses parenthesis
[ ] brackets bracket
{ } braces brace
< > chevrons chevron

Advantages

  • concise
  • understood by people familiar with writing and typography
  • somewhat used in the code base

Disadvantages

  • people may be unsure which concepts parentheses, brackets, braces, and chevrons refer to
    • we could explain these thoroughly in fixer descriptions, though

Unclear

Sources

(Feel free to add more)

Aside

As an aside, in German these are all Klammern:

Characters Plural Singular
( ) Klammern Klammer
[ ] eckige Klammern eckige Klammer
{ } geschweifte Klammern geschweifte Klammer
< > spitze Klammern spitze Klammer

@coveralls
Copy link
Copy Markdown

Coverage Status

coverage: 95.141%. remained the same
when pulling a275224 on keradus:3.0_brackets
into 9dc4237 on PHP-CS-Fixer:master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider renaming new_with_braces to new_with_parentheses

9 participants