DEV Community: Cédric Françoys

Style Guide Proposal: Parentheses and Braces in PHP

Cédric Françoys — Sat, 14 Jun 2025 17:10:40 +0000

Objective

This document presents a thorough reflection on how to establish a readable, rigorous, and coherent coding syntax for the use of parentheses and braces in PHP. Rather than perpetuating historical conventions inherited from languages like C or Java, it is based on a clear principle: code should reflect the logic of the language, not formatting habits.

The goal of this proposal is to define a style that is:

Unified: one rule applies uniformly across all relevant constructs—functions, control structures, or inner expressions;
Systematic: each rule follows directly from syntactic structure, not from lexical category (keyword, identifier, etc.);
Consistent: treatment is aligned across similar cases, with no arbitrary exceptions;
Easy to remember: by eliminating contextual variations and aesthetic distinctions with no functional value.

We aim to define a stylistic syntax that requires no extra effort in visual classification but aligns closely with the intrinsic mechanisms of PHP.

Syntax should follow structure, not appearance

PHP has an explicit grammar where the syntactic category of each construct (function, control structure, expression) is clearly distinguishable by any developer familiar with the language. Therefore, it is unnecessary to introduce stylistic variations based solely on the lexical appearance of preceding elements.

For example:

if($x > 0) {
    ...
}
foo($x);

In the first case, if is a control structure; in the second, foo is a function. Both use parentheses to wrap an expression. Yet, common conventions (e.g., PSR-12) require a space after if but forbid a space after foo.

Why apply two different rules to the same syntactic form? This discrepancy adds no real readability. A developer can already distinguish between if and foo. Style should not compensate for distinctions that are inherently clear in the language.

Similarly, braces {} are lexical scope delimiters. Their placement should follow a consistent principle regardless of context—whether opening a function, a loop, or any other block.

The central thesis is: a shared syntactic structure should imply a shared visual representation, independent of the preceding token's semantic role (keyword or identifier).

Inherited conventions introduce confusion

Prevalent style guides such as PSR-2 and PSR-12 inherit patterns from C-like languages. They enforce distinctions in formatting between constructs that are structurally similar. For example:

A function declaration must place its opening brace on the next line:

  function foo()
  {
      ...
  }

A control structure like if must place the brace on the same line:

  if ($x > 0) {
      ...
  }

A space is required after if, but forbidden after foo().

These distinctions are justified by aesthetic or historical preferences rather than grammatical necessity. They introduce a needless cognitive load, requiring developers to memorize exceptions instead of applying a predictable rule.

They also complicate the implementation of formatting tools, which must apply conditional logic rather than universal patterns. In collaborative settings, these irregularities can lead to stylistic debates or merge conflicts that are purely formal.

In the end, these conventions hinder clarity and maintainability for the sake of outdated visual expectations.

Synthesis: Toward a uniform, logical, and rule-based syntax

A better alternative is to derive style directly from the language's actual structure. This means:

No space before opening parentheses, regardless of preceding token: if($x), while($y), foo($z).
Opening braces always on the same line as the controlling statement: function bar() {, if($x) {.
Closing braces alone on their own line, aligned with the block start.

This results in:

Simplified comprehension
Seamless compatibility with automated formatting tools (e.g., PHP-CS-Fixer, linters)
A visually clean and vertically structured codebase

The benefits are twofold:

For individual developers: fewer edge cases to remember, greater focus on logic
For teams: less friction in code reviews, clear conventions easy to share and enforce

Special case: `if/elseif/else` and `try/catch/finally`

A specific question arises regarding if/elseif/else and try/catch/finally, where it is common to begin the next block directly after a closing brace:

if($x) {
    ...
} elseif($y) {
    ...
} else {
    ...
}
try {
    ...
} catch(Exception $e) {
    ...
} finally {
    ...
}

While syntactically valid and widely accepted, these are the only cases where a new structure follows immediately after a closing brace on the same line.

Following the principle of minimizing stylistic exceptions, this behavior should be reconsidered. Specifically:

PHP does not require chaining these blocks on the same line.
Although else, catch, and finally are syntactically dependent (they cannot start independently), this does not justify a distinct visual form.
Maintaining vertical alignment enhances structure visibility.

Proposed rule

All blocks (if, else, elseif, try, catch, finally) must start on a new line after the previous block’s closing brace.

This ensures:

No stylistic exceptions
Clear vertical structure
Uniform block detection

Preferred example:

if($x) {
    ...
}
elseif($y) {
    ...
}
else {
    ...
}
try {
    ...
}
catch(Exception $e) {
    ...
}
finally {
    ...
}

This rule aligns fully with the overall goals of this guide: to reduce special cases and avoid tying formatting to specific keywords.

Modern extensions: arrow functions and ternary expressions

Some newer constructs in PHP raise stylistic questions, though they typically do not involve braces.

Arrow functions (`fn`)

Introduced in PHP 7.4, these use parentheses for parameters and a single expression (no braces).

Guideline:

No space between fn and (:

  $f = fn($x) => $x + 1;

Don't

  $f = fn ($x) => $x + 1;

Ternary expressions (`? :`)

These are expression-level constructs. The goal is to promote clarity:

Guidelines:

Use parentheses to wrap nested or complex sub-expressions.
Insert spaces around ? and : like any binary operator.

Examples:

$result = $x > 0 ? 'positive' : 'negative';

$message = ($x > 0)
    ? ($x > 10 ? 'large' : 'small')
    : 'zero';

These are not subject to brace-related rules and are best covered by expression formatting standards.

Conclusion

A style rule has value only if it enhances structure without interfering with it. Code should reflect program logic—not act as a canvas for visual conventions.

By choosing a unified syntax based on structural grammar, this guide offers a rational, consistent, and modern approach to writing PHP. It abandons historical formatting quirks in favor of sustainable, generalizable principles.

This is not about personal preference, but about redefining the foundations of PHP style on clear, durable, and logically grounded rules. The following sections will present each rule, its application, edge cases, and practical implications.

A Note on Perspective and Adoption

I am fully aware that proposing an alternative style guide is unlikely to change much. While this document lays out a coherent and logically structured alternative, I have little hope it will shift the current conventions in any significant way.

Most developers don’t genuinely care about syntactic consistency—as long as their code runs, builds, and passes the linter. Habits are deeply entrenched. Furthermore, the prevalence of established standards like PSR means that any deviation, however justified, is perceived as unnecessary friction.

And the arrival of AI doesn’t help. On the contrary, it reinforces the inertia. Most code generated by AI tools blindly follows existing PSR-style rules. The AI doesn’t reason about syntax—it imitates. The more these tools are used, the more the current conventions become self-reinforcing, regardless of whether they were ever truly optimal.

This guide is not an attempt to fight that tide. Rather, it is an exercise in principled reasoning. If the future of coding is to be increasingly automated, we should at least strive to encode principles that are internally consistent, teachable, and deducible—rather than inherited from historical precedent or aesthetic legacy.

End-to-End Application: A Complex Challenge

Cédric Françoys — Tue, 20 Aug 2024 12:24:03 +0000

Developing an end-to-end application is an extremely complex task that requires a multitude of skills that few individuals possess alone.

That's where FullStack developers come in.

To overcome this challenge, it is crucial to implement advanced strategies and architectures that promote scalability, maintainability, and security.

One of the most effective approaches is adopting microservices. By dividing the application into small, independent services, each responsible for a specific functionality, management and evolution of the whole are facilitated. This modularity is further enhanced by containerization, which allows these services to be deployed and managed consistently across different environments, simplifying deployment and increasing scalability.

Going even further, serverless architecture offers a solution where developers can focus exclusively on the code without worrying about server management, while benefiting from automatic scalability. This approach is often combined with an API-First design, ensuring that integration and communication between different services and components are smooth and efficient.

In terms of reactivity and real-time processing, Event-Driven Architecture is a wise choice. By structuring the application around events, its responsiveness and ability to handle variable loads can be significantly improved.
At the same time, Domain-Driven Design (DDD) helps structure development around the business domain, offering a model-centric approach to solving complex problems.

CQRS (Command Query Responsibility Segregation) adds another dimension by separating read and write operations, thus optimizing performance and scalability. This philosophy is complemented by Hexagonal Architecture, which isolates the business domain from user interfaces and infrastructure, making the application easier to test and evolve.

To structure the application modularly, Layered Architecture (or MVC) remains a classic. It clearly separates presentation, business logic, and data access responsibilities. In an increasingly cloud-centric world, adopting Cloud-Native Architecture becomes indispensable for fully leveraging the services and features of cloud providers.

Security and compliance cannot be overlooked. Implementing robust authentication mechanisms, such as OAuth or JWT, is essential to secure application access. Concurrently, defining and enforcing strict security policies ensure the protection of sensitive data and compliance with current regulations.

Adhering to relevant ISO standards is also crucial to ensure the quality and security of the application. Finally, adopting Test-Driven Development (TDD) and implementing continuous integration and deployment pipelines (CI/CD) not only improves code quality but also accelerates the development cycle.

By being aware of these strategies and best practices, it becomes possible to navigate the complexity of developing an end-to-end application, even for a stand-alone fullstack developer.

If you're looking for a framework to achieve that: have a look at this open source framework : https://github.com/equalframework/equal

Dates References: A Timely Affair

Cédric Françoys — Wed, 12 Jun 2024 19:35:15 +0000

One notation to rule them all

For some time now, I've been working on a Web App framework, and this led me to think about a lot of things, amongst which data typing.

eQual provides a structured way to reference dates allowing to describe and retrieve any date based on the current date, which can be used in Domains for filtering or conditioning visibility.

Date References allow to reference dates relatively to various intervals and dynamically compute dates for a wide range of scenarios by combining methods and parameters.

A Date Reference descriptor is built using the following structure :

date.<origin>(<offset>).<interval>.<method>(<arguments>)

or, in a more explicit notation :

date.{this|prev|next}[(<offset>)].{day|week|month|quarter|semester|year}.{first|last|get(reference:index)}

Attributes and Arguments

1. Origin

Method	Description	Offset	Possible Values
prev(n)	Previous period with an offset of n intervals	n > 0	`prev`, `prev(n)`
next(n)	Next period with an offset of n intervals	n > 0	`next`, `next(n)`
this()	Current period (n=0 by default)	n = 0	`this`, `this(0)`

2. Interval

Interval	Description
day	Day
week	Week
month	Month
quarter	Quarter
semester	Semester
year	Year

3. Method

Method	Description
first()	First day of the interval
last()	Last day of the interval
get()	Get a specific date with arguments

Tables of Possible Values

Origin

Method	Possible Values
`prev(<increment>)`	`prev`, `prev(0)`, `prev(n)` (n ≥ 0)
`next(<increment>)`	`next`, `next(0)`, `next(n)` (n ≥ 0)
`this()`	`this`, `this(0)`

Interval

Interval	Description
`day`	Day
`week`	Week
`month`	Month
`quarter`	Quarter
`semester`	Semester
`year`	Year

Method

Methods can be applied on the chosen interval (except for day, for which the method has no effect).

Method	Description
first()	First day of the interval
last()	Last day of the interval
get()	Get a specific date

Arguments for the `get()` Method

Argument	Concerned Interval	Possible Values
day:	month, quarter, semester, year	Month: `day:1` to `day:31` Year: `day:1` to `day:365`
week:	month, quarter, semester, year	`week:1` to `week:52` (or `week:53`)
:first	month, quarter, semester, year	`monday:first` to `sunday:first`
:last	month, quarter, semester, year	`monday:last` to `sunday:last`
:	month, quarter, semester, year	`monday:1` to `monday:5` (month) `monday:1` to `monday:14` (quarter) `monday:1` to `monday:26` (semester) `monday:1` to `monday:52` (or `monday:53`) (year)

Usage Examples

today
```
date.this.day
```
Seven days from now
```
date.next(7).day
```
First day of the month 5 months before the current month:
```
date.prev(5).month.first()
```
Last day of the quarter 2 quarters after the current quarter:
```
date.next(2).quarter.last()
```
34th week of the next year:
```
date.next(1).year.get(week:34)
```
First Monday of the semester 3 semesters before the current semester:
```
date.prev(3).semester.get(monday:first)
```
Second Wednesday of the month 4 months after the current month:
```
date.next(4).month.get(wednesday:2)
```

first day of current year:

date.this.year.first

date.this.year.get(day:1)

Not my type: Types Vs. Usages

Cédric Françoys — Sun, 22 Oct 2023 15:57:30 +0000

An irreverent yet positively innovative approach regarding data typing

I love programming. I discovered the computers and wrote my first programs when I was a kid and I've never stopped since then.

For some time now, I've been working on a Web App framework, and this led me to think about a lot of things, amongst which data typing.

It took me quite a long time to realize that the conventional approach of using variable types in most programming languages leads developers to create programs that require tremendous efforts to deal with validation, adaptation, storage and rendering of the manipulated values.

The reason is that traditional data typing in programs is very permissive, tends to prioritizes technical needs over human reasoning, often lacks of context validation, and is rarely explicit in terms of human representation.

This article presents a solution that aims to tackle these limitations by suggesting a more complete, flexible and unambiguous way to define and to handle data.

TL;DR

If, when declaring...	You intend to deal with...
`let country:string`	"a two letters code of a country that complies with ISO3166"
`float amount`	"an amount of money with a precision of 4 decimal digits"
`string email`	"an email address that complies with IETF RFC 5322 & RFC 6854"
`string password`	"the blowfish encrypted version of a password complying with NIST recommendations"

Then you're using an ambiguous typing and you probably have to manually deal with validations and conversions.

This article presents the advantages of using an explicit typing, and suggests that a simple syntax inspired by the Media Type notation could be used as a supplement or even as a replacement to traditional data types.

type [ ["/" subtype[.variation][":" length]] ]["{" min, max "}"]

Example: "A money amount with up to 12 integer digits and 4 decimal digits" (FASAB/GAAP compliant) :

amount/money:12.4

Did you say Variable ?

As a developer, I deal with variables and types all the time. It is so common that it has become difficult to explain what exactly is a variable.

Let's try anyway.

All programming languages rely on data types in order to define how each piece of data has to be stored in memory, and to guarantee that operations performed on the data are consistent.

Programs use names to identify the memory locations that are assigned for storing the data. These names are called "variables".

In most cases, the value stored in a variable can change during the execution of the program (which is why it is called a "variable").

A variable can be used in computations, assigned to other variables, or passed as argument to functions or methods.

Most programming languages use types as classification of variables based on the kind of data they represent.

The most common types, used in nearly all programming languages, are : bool(ean), int(eger), float(ing-point number), and string.

The whole picture

Whatever the purpose of the processing, when a program handles variables there are 4 key considerations from the developer perspective:

Data Model (Validation): Ensuring that the submitted value complies with the Model defintion and the application logic.
Data Storage (Allocation): Determining the amount of memory required to store the variable (i.e. how many bytes).
Data Exchange (Adaptation): Manipulating the data to convert it from one format to another (example: data exchange through API).
Data Representation (Formatting): Specifying how the data should be displayed for human reading. (Sometimes there are some conventions for representing a data : a phone number, an email address, a monetary amount, a percentage value, ... This aspect might also depend on the user's language & locale).

In most cases, programming languages deal with a single concept of "type" to manage all these considerations, which often turns out to be incomplete or even impossible. And some of (and sometimes all of) these tasks are left to the discretion of the developer on a case-by-case basis.

Data Model (validation)

Data modeling consists of telling the kind of data (human concept) that is stored into a variable (computer concept), and specifying if some constraints must be applied on a variable. The questions it addresses are "how to validate it" and "what operations can be performed on it".

In most situations, the type of a variable is used to control the operations that can be performed on it. It is also used to check that the variable that is passed as parameter to a function has the expected type, based on the function signature.

This is because the intended use of a piece of data always has some implicit restrictions. As a consequence, some operators might be forbidden for variables of a certain type. For instance, the operator / is valid for numbers (means "perform a division") but doesn't make sense for strings.

Also, depending on the language, a same operator might have distinct meaning depending on the type of the operands. For instance, in JS or C++, using the operator + on numbers means "perform an arithmetic addition on these values" while using it on strings means "concatenate these strings".

Observations :

Most languages allow developers to define variables amongst the following models : character, number, string, binary value and array.

But these types can describe a lot of things:

a string can be used for storing a name, a country, an address, ...
a number can represent a quantity, an index, or even a date
a binary value might be a document, an image, an archive, ...

The Model should not only tell "What it is" but also "What it is intended for". Doing so makes it possible to bind some constraints to a variable. And the advantage of having constraints bound to data types is that, in case a submitted value does not comply with what is expected, it is easy to automatically provide the user with an accurate feedback about the reason why its submission was rejected.

Data Storage (allocation)

Data storage relates to the amount of memory the computer must reserve in order to store the variable. The question it addresses is "what amount of memory must be allocated".

Types are almost always used to tell the computer how much memory (what amount of bytes) should be allocated for storing the value of a variable.

In the early days of computing, when every byte was valuable, resource allocation efficiency was a crucial consideration. And the rigor in the choice of the most appropriate type in terms of memory was decisive in order to take advantage of the least available bit. But it also resulted in not very intuitive and sometimes ambiguous notations. For instance, in C and C++, the int type can be stored on 2 or 4 bytes depending on the environment.

Here are the elementary computer memory units:

bit: 1 binary digit
byte: a 8-bits (the smallest addressable unit of memory in most architectures)
string: a series of bytes of an arbitrary length
integer: a block of bytes used to represent an integer value, which length depends on the computer architecture

The way types are defined depends mostly on machine architecture (CPU registers capacity: 16 bits, 32 bits, 64 bits, ...) and on common values expected to be manipulated for different levels of precision (min, max) according to Byte multiples (int32, unsigned int, long long int, ...)

Here are a few examples of variable declaration (as it can be found in common programming languages) that are ambiguous for humans in terms of memory allocation:

Declaration statement	Comments
`const N:u8` (Rust)	an unsigned integer stored on 8 bits (i.e. a natural number between 0 and 255)
`Dim n As Byte` (VB)	(idem)
`double n` (C++)	a real number with "double" precision (unclear about min and max values)
`let n:number` (TS)	any integer or floating point number (also unclear about min and max values)
`let n:i32` (Rust)	not easy for humans to tell the limits (something like "a range between -2 billons and +2 billions")
`unsigned long long n` (C++)	(who the hell knows the result of 2^64-1 ?)

Observations :

Telling how a variable must be stored by using an integer number of bytes might have been necessary in the past, but it is not the case anymore: typing should not be confused with memory allocation.
Any application uses a hardware-software stack which has implications in terms of limits (maximum number of digits, precision of the floating number). However, this stack is likely to evolve over time, and so are these limitations. Therefore, the logic of an application should be decoupled from the stack. That way, it would be easier for the developer to ensure that the storage/memory allocation remains consistent with the App logic.
Typing should not only focus on how to store the data but also on how to translate human concepts to something that a computer can (easily) handle. If capability for humans to read the resulting source code is maintained, it greatly eases the work of the developers while adapting, maintaining or improving the code.

Data Exchange (adaptation)

Data Exchange relates to the transfer of data and variables from one environment to another. The question it addresses is "How to convert a piece of data received from the outside into a local variable and convert it back for sending a response".

Each environment might store variables using its own types and representations.

When the application receives data from the outside, nothing guarantees that it can be converted from the input format to a native format (programming language) in a consistent way, and without exceeding the capacity of the underlying layers (available/allocated memory).

The same goes for sending data : we have no clue about how to format the data so that is it correctly interpreted, apart from the notation suggested by official norms like ISO. But again, nothing guarantees that the system we're communicating with follows these standards.

Observations :

A variable should be seamlessly convertible to another format according to the target specifics (ex. JS, PHP, SQL)
A type should allow distinct programs or computers to handle the data in a consistent way.
An application should communicate about the parameters it expects along with the inherent limitations (expected format, maximum size, etc.)

Data Representation (formatting)

Data representation relates to the encoding of a value in a way that makes it understandable by humans and valid within a given context. The question it addresses it "How to display it within a given context?".

For some types of variables, outputting data is not trivial and can involve a lot a possible variations (for instance when preferences or user settings are involved). In such case, it is necessary to be explicit about how the data must be displayed.

An additional difficulty is that some representations might vary depending on the "locale" settings (e.g. character for decimal separator) or international variations of notations (e.g. amount of digits of a phone number or digits grouping convention).

Dates are a good example: various strategies can be found depending on the tools and environments (timestamps, formatted strings, ISO notation). And this matter is still subject to many issues is modern softwares.

Observations :

Typing should allow both computers and humans to know how to present the value of that variable.
For types that may be represented in many different ways (ex. dates / datetimes), an additional piece of information is necessary for disambiguation.

Explicit typing

Unlike computers, humans know that a real is a number and that a string is a piece of text. On the other hand, unlike humans, computers need to know beforehand how much memory must be allocated in order to store a real number or a string.

The problem is that the human definitions of "text" and "number" are quite vague. Respectively: "a coherent set of signs that transmits some kind of informative message"; and "symbols that represents an amount" and give no clue about storage or rendering.

To enable a computer to handle a value accurately, without requiring the developer to program in every detail how to store and manipulate it based on its intended use, the associated variable should have an explicit type.

In other words, explicit typing describes a variable in a way that covers the 4 aspects presented above : modeling, allocation, adaptation and formatting.

Proposition

The suggestion made in this article is that explicit typing can be achieved by using a single descriptor.

Here below, is a proposal in the form of a proof of concept, that uses a notation logic close to the the Media Type syntax (MIME) for building such descriptors.

Using the MIME notation, in conjunction with concepts for which an unambiguous definition or an international standard exists, provides an explicit typing. For instance, we can assume that a "language" is a value that holds 2 or 3 lowercase letters and whose possible values are provided by the ISO standards ISO-639-1 and ISO-639-2.

The term "usage" is used to distinguish explicit types from primitive types.

Here is the full syntax of a "usage" descriptor:

type [ ["/" subtype[.variation][":" length]] ]["{" min, max "}"]

type is the name of the non-primitive type;
subtype is the mandatory categorization of the non-primitive type (example: number/integer). It always has a default value so it can be omitted (ex. text defaults to text/plain);
variation (optional) additional meta information to identify a specific standard or norm (example: hash/md.4);
length is either an amount of digits (or glyphs), or a length under the form precision.scale;
- for numeric values, the length tells the amount of digits (required bytes can be found with ceil(log2(x) / 8);
- for strings, the length indicates the amount of glyphs (which might differ from the number of bytes);
- for usages that imply a floating point numbers, the length can be composed of several parts separated with dots (e.g. precision[.scale]).
min and max are optional parameters intended for numbers and can be used for defining custom limits. By default, there are always limits, set based on the min and max implied by the usage. If set, these values must be consistent with the length (for instance number/natural:2 cannot have a min lower than 0 nor a max higher than 99).

The primitive types can coexist, but become special cases of the "usage".

The proposition being that:

A usage always relates to a generic type (by example, all variations of "number/real" relate to the type "float");
All generic types are associated with one default usage;
The default boundaries depend on the local environment and off-limit values should be rejected by it.

Examples

Below is presented a non-exhaustive list of descriptors using such notation.

Usage	Primitive Type	Description	Examples
TEXTS
text/plain	string	A regular string composed of unicode chars (UTF-8 4-byte) Alias: text, text/plain.short, text/plain:255 Variations: text/plain.small (65KB) text/plain.medium (16MB), text/plain.long (4GB)	Hello world.
text/xml		An XML formatted string (equivalent to MIME "application/xml")	<Person> <Name>Joe</Name> </Person>
text/html		An HTML formatted string.	<p>HTML rocks!</p>
text/markdown		A piece of text using MarkDown notation.	## Title
text/wiki (markup/wikitext)		A piece of text using Wiki markup.	''italic''
NUMBERS
amount/money		A financial amount Alias: amount/money:9.2, amount/money:2 Variations: amount/money:9.4 (FASAB/GAAP)	886.90 EUR
amount/percent		A percentage Alias: amount/percent:2	85.13%
amount/rate		A rate amount (with no units). Alias: amount/rate:4 Variations: amount/rate:6	1.0789
number/boolean	bool	Alias: number/boolean:1
number/natural		A positive integer (ISO 80000-2: [0;99]) Alias: number/natural:9 (32bit) or number/natural:19 (64 bits) Example : number/natural:2 (2 digits positive integer)	0, 25, 999
number/integer	int	Alias: number, number/integer.decimal Variations: number/integer.hexadecimal, number/integer.octal Examples: number/integer:1 (a single digit integer: [-9;+9])	-32767, 1, 65535
number/real	float	Alias: number/real:10.2 Example: number/real:5.2 (a float number with 2 decimal digits and max 3 digits for the integer part)	123.45
URI
uri/url.http		A URL using HTTP or HTTPS scheme.	https://equal.run
uri/url.ftp		A URL using FTP and FTPS scheme.	ftp://ftp.example.com
uri/urn.isbn		An International Standard Book Number for identifying a book Alias: urn/isbn:13 or urn/isbn.13 Variations: uri/urn.isbn:10 (ISO 2108)
uri/urn.isan		International Standard Audiovisuel Number for identifying and audiovisual	ISAN 0000-0000-3A8D-0000-Z-0000-0000-6
uri/urn.iban		International bank account number (ISO-13616) Variations: urn/iban.BE (or urn/iban.16 or urn/iban:16)
uri/urn.ean		International article numerotation EAN number (ISO-15420) Alias: urn/ean.13 or urn/ean:13
DATES
date/plain		An ISO 8601 date with date part only [@00:00:00UTC]) Alias: date	1955-11-05
date/time		A full ISO 8601 date holding an UTC time. Alias: datetime	1955-11-13T05:04:00Z
date/year		Alias: date/year:4 (integer 0-9999) Variations: date/year:2	1999
date/month		An integer representing a month within the year (ISO-8601 : 1 to 12, 1 being January)	11
date/weekday		An integer representing a day within the week (ISO-8601: 1 to 7, 1 being Monday) Alias: date/weekday.mon Variations: date/weekday.sun (0 to 6, 0 is Sunday)	3
MISC
email		A string describing an email address as defined by IETF RFC 5322 & RFC 6854	cedric@equal.run
language		A language represented with 2 lower case letters (ISO 639-1) Alias: language/iso-639:2 Variations : language/iso-639:3 (ISO 639-2)	en, de, zh
country		A country represented with 2 upper case letters (ISO 3166-1 alpha-2) Alias: country/iso-3166:2 Variations: country/iso-3166:3 (ISO 3166-1 alpha-3)	FR, GB
image		A binary value representing an image. Variations: image/jpeg, image/gif, image/png, image/tiff, image/webp	.PNG........IHDR..............wS.....IDAT..c.................IEND.B.
password		A password complying to NIST 800-63 (minimum length of 8 chars, unicode chars) Alias: password/nist, password/enisa

Note: if you're interested in more examples or have any suggestions, feel free to explore the complete list of Usages on this Gist.

Numbers boundaries

When it comes to numbers, it is common for a variable not to relate to any standard or external convention, but instead to have boundaries (i.e. minimum and maximum possible values).

For that, we can use a notation similar to the one used in regular expressions for {n,m} quantifiers (https://docs.oracle.com/javase/tutorial/essential/regex/quant.html)

Here are a few examples:

general	with boundaries	description
number/integer	number/integer{-10,10}	an integer within the range [-10;10]
amount/money:6.4	amount/money:6.4{0,300000}	a money amount between $0.0 and $300,000 examples: 299999.9999

This technique can be advantageously extended to strings to define specific lengths:

general	with boundaries	description
text/plain	text/plain{2,30}	a string having minimum 2 glyphs and maximum 30 glyphs

Handling Arrays

Array is a kind of super type. It has a length (that can be dynamic), and holds elements of a specific type.

Various notations for arrays can be found among popular programming languages. The most usual notations are :

Array<Type>
Type[] or Type()
[Type; size]or Type[size]

In order to respect the assumptions made earlier, and make it easily usable in controllers (validation only), we should be able to determine the maximum length of the array, along with the kind of elements it holds.

For arrays as well, Usage can helpfully complete the information about the handled data:

we know the variable holds a series of items and we know how to store, validate, display and convert those items.

// Array holding 3 integers having max 2 digits 
// (#memo - type is a special case of a broader usage)
[
  'type'   => 'array',
  'usage'  => 'number[3]/integer:2'
];

// Array
[
  'type'  => 'array',
  'usage' => 'email[10]'
];

There is a special case of non-typed arrays that may be used in order to accept arbitrary values or maps.

// special case non-typed array 
// (#memo - applies only to input params not meant to be stored)
[
  'type'  => 'array'
  'usage' => 'array'
];

Additional benefits

This approach can be used for identifying (or guessing) the kind of data that a field stores, which can be useful in various situations :

Sensitive data

When using production data within a DEV or Staging environment, this approach allows to identity sensitive or privacy-related data.

Having a Usage telling the kind of value we're dealing with (ex. name, birthdate, gender, address, email, iban, password) allows developer to identify which values must be obfuscated (withdrawn or randomized) before importing data to the test environment, and/or with what sample data they can be replaced.

Also, for record-based backups, it can be used to tell which columns must by encrypted.

Sample data (DB seeding)

In the same way, coupling properties with Usages makes it easy to generate sample sets for seeding a database with dummy data in a consistent way.

If your curious about this or would like to see an example of implementation, you can have a look at the eQual framework.

Here are the direct links to the involved files in the repository :

Valuable sources consulted over time

https://en.wikipedia.org/wiki/Data_type
https://en.wikipedia.org/wiki/Media_type
https://www3.ntu.edu.sg/home/ehchua/programming/java/datarepresentation.html
https://www1.icsi.berkeley.edu/~sather/Documentation/EclecticTutorial/node5.html
https://www.lehigh.edu/~ineng2/notes/datatypes
https://doc.rust-lang.org/nomicon/repr-rust.html
https://docs.oracle.com/javase/tutorial/essential/regex/

DEV Community: Cédric Françoys

Style Guide Proposal: Parentheses and Braces in PHP

Objective

Syntax should follow structure, not appearance

Inherited conventions introduce confusion

Synthesis: Toward a uniform, logical, and rule-based syntax

Special case: if/elseif/else and try/catch/finally

Proposed rule

Preferred example:

Modern extensions: arrow functions and ternary expressions

Arrow functions (fn)

Ternary expressions (? :)

Conclusion

A Note on Perspective and Adoption

End-to-End Application: A Complex Challenge

Dates References: A Timely Affair

Attributes and Arguments

1. Origin

2. Interval

3. Method

Tables of Possible Values

Origin

Interval

Method

Arguments for the get() Method

Usage Examples

Not my type: Types Vs. Usages

TL;DR

Did you say Variable ?

The whole picture

Data Model (validation)

Data Storage (allocation)

Data Exchange (adaptation)

Data Representation (formatting)

Explicit typing

Proposition

Examples

Numbers boundaries

Handling Arrays

Additional benefits

Sensitive data

Sample data (DB seeding)

Next

Valuable sources consulted over time

Special case: `if/elseif/else` and `try/catch/finally`

Arrow functions (`fn`)

Ternary expressions (`? :`)

Arguments for the `get()` Method