WordPress community has created a set of coding standards that need to be followed when contributing to the WordPress Core and are encouraged to be used elsewhere in themes and plugins.

Quoting directly from WordPress Docs:

While themes and plugins may choose to follow a different coding style, these coding standards are not just about code style, but also encompass established best practices regarding interoperability, translatability, and security in the WordPress ecosystem, so, even when using a different code style, we recommend you still adhere to the WordPress Coding Standards in regard to these best practices.

General

Opening and Closing PHP Tags

When embedding PHP in HTML, the opening and closing PHP tags must be the only content on that line.

Single line PHP opening and closing tags are allowed.

Important: Shorthand PHP tags are not allowed, use full PHP tags.

Single and Double Quotes

Use Single Quotes as much as possible in all the circumstances unless evaluating something.

Never escape quotes use the other quotes when needed.

Include/require statements

Use require as much as possible.
Do not use parenthesis, there should be only one space between require and file path.

// Correct.
require_once ABSPATH . 'file-name.php';

// Incorrect.
include_once  ( ABSPATH . 'file-name.php' );
require_once     __DIR__ . '/file-name.php';

Naming

Variables

Use snake_case never use camelCase. Separate words using _(underscore).

Objects

Class, trait, interface and enum names should use capitalized words separated by underscores. Any acronyms should be all upper case.

Class file names should be based on the class name with class- prepended and the underscores in the class name replaced with hyphens.

Only one Object Structure (Class/Interface/Trait/Enum) per File.

For all constructs, visibility should be explicitly declared.

class Walker_Category extends Walker {}
class WP_HTTP {}

interface Mailer_Interface {}
trait Forbid_Dynamic_Properties {}
enum Post_Status {}

Constants

Constants should be in all upper-case with underscores separating words

Namespace declarations

Namespace declarations should have exactly one blank line before the declaration and at least one blank line after.

Inline Documentation Standards

Documentation for all the functions, class methods, Classes, Class members (including properties and constants), requires and includes, hooks (actions and filters), inline comments, file headers, and constants must be provided.

Functions and Classes

For all the functions and classes, summary, description, @params and @return must be defined. Summary must be on one single line, description must go in detail about what the function does.

/**
 * Summary.
 *
 * Description.
 *
 * @since x.x.x
 *
 * @see Function/method/class relied on
 * @link URL
 * @global type $varname Description.
 * @global type $varname Description.
 *
 * @param type $var Description.
 * @param type $var Optional. Description. Default.
 * @return type Description.
 */

Requires and Includes

Any of the imports must have a short summary.

Hooks

Both action and filter hooks should be documented on the line immediately preceding the call to do_action() or do_action_ref_array(), or apply_filters() or apply_filters_ref_array().

/**
 * Summary.
 *
 * Description.
 *
 * @since x.x.x
 *
 * @param type  $var Description.
 * @param array $args {
 *     Short description about this hash.
 *
 *     @type type $var Description.
 *     @type type $var Description.
 * }
 * @param type  $var Description.
 */

Conclusion

These coding standards must be followed in order to contribute to WordPress Core and also in general for all of the theme and plugin projects to have maintainable code base.