Code conventions: Difference between revisions

From Nasqueron Agora
No edit summary
No edit summary
 
(24 intermediate revisions by the same user not shown)
Line 4: Line 4:
* [http://jeroendedauw.github.io/slides/craftmanship/functions/#/1 Keep functions short and simple].
* [http://jeroendedauw.github.io/slides/craftmanship/functions/#/1 Keep functions short and simple].
* Define explicitly methods visibility, as several languages have different default values (e.g. private for C# class members, public for PHP methods)
* Define explicitly methods visibility, as several languages have different default values (e.g. private for C# class members, public for PHP methods)
* Comments to document a method are written at the singular 3rd person (we seem to have moved to infinitive recently, we need to take a decision here)


== C ==
== C ==
If you use [http://clang.llvm.org/docs/ClangFormat.html ClangFormat], a [https://github.com/dereckson/rabbitmq-tcl/blob/master/.clang-format .clang-format file] is available.
If you use [http://clang.llvm.org/docs/ClangFormat.html ClangFormat], a [https://github.com/dereckson/rabbitmq-tcl/blob/master/.clang-format .clang-format file] is available.
== JavaScript ==
The following conventions are used:
* K&R, 1TBS variant, including for functions
* 4 spaces as indent
* Use modern JavaScript idioms like <code>const</code> and <code>let</code> instead of <code>var</code>
* Consider to use async code for events-driven development, especially for servers


== PHP ==
== PHP ==
The following conventions are used:
* K&R, 1TBS variant, including for functions
* K&R, 1TBS variant, including for functions
* 4 spaces as indent
* 4 spaces as indent
* The keywords true, false and null must be in lower case.
* The keywords <code>true</code>, <code>false</code> and <code>null</code> must be in lower case.
* Arrays use short syntax
* Arrays use short syntax
* Array elements ends with a comma
* Array elements ends with a comma
* Functions, methods and class names use camel case
If you use PhpStorm or another JetBrains IDE, you can import [https://github.com/nasqueron/codestyle/blob/master/JetBrains/php-codestyle.xml JetBrains/php-codestyle.xml] from the codestyle repository as a code style (Settings or Default Settings > Editor > Code Style > PHP > click on the wheel icon > Import Scheme > Intellij IDEA codestyle XML).
If you want to lint a project with phpcs, you can require the Composer package <code>nasqueron/codestyle</code> and use the following <kbd>phpcs.xml<kbd> standard file:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<ruleset>
    <rule ref="vendor/nasqueron/codestyle/CodeSniffer" />
    <file>.</file>
    <exclude-pattern>\.git/</exclude-pattern>
    <exclude-pattern>vendor/</exclude-pattern>
</ruleset>
</syntaxhighlight>


== Python ==
== Python ==
We follow [https://www.python.org/dev/peps/pep-0008/ PEP-8].
'''2023.''' We follow [https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html black style], so use black utility (<code>pip install black</code>). As such, you need to configure Flake8 to ignore rule E203.
 
'''2015.''' We follow [https://www.python.org/dev/peps/pep-0008/ PEP-8].


== Rust ==
== Rust ==
We follow Rust default style, described at https://aturon.github.io/. It's mainly a K&R, 1TBS variant.
'''2023.''' Automated codestyle (black in Python, clang-format in Rust) seems preferable. As such, a style compatible with <code>rustfmt</code> is needed to be able to format using <code>cargo fmt</code>. You can add to your project  [https://devcentral.nasqueron.org/source/codestyle/browse/main/rust/rustfmt.toml rust/rustfmt.toml in codestyle] to configure it.
 
'''2015.''' We followed "Rust default style", described at [https://web.archive.org/web/20170320083740/http://aturon.github.io/ https://aturon.github.io/]. It's mainly a K&R, 1TBS variant.


Use trailing comma for elements in every struct/impl/etc.
Use trailing comma for elements in every struct/impl/etc.
== Salt ==
=== Style ===
Whitespaces:
* Indent with two spaces
* YAML lists use indented bullets
<syntaxhighlight lang="yaml">
id:
  method:
    - somekey: value
    - otherkey: value
</syntaxhighlight>
=== Tips ===
;Files provisioned
* When you ask to download a file remotely, you need a source hash, pick SHA256 as algo
* Each file provisioned from the Salt repository must contains an header explaining the fact, with the full path in the rOPS repo
;BSD and Linux distros compatible states
* populate the map.jinja file with OS logic (e.g. `dirs` for /etc vs /usr/local/etc)
* when you've a specific set of tasks to do for one OS/distro, it's acceptable to enclose it in a state by an if block
=== Vocabulary ===
;Domain names
:To refer to the fully qualified domain name sub.domain.tld, use '''fqdn'''. To split the domains in part, use '''domain''' and '''subdomain'''. This is important to understand a state without having  to refer to the associated pillar to disambig domain.


== Shell scripts ==
== Shell scripts ==
UNIX agnosticism:
UNIX agnosticism:
* Don't assume absolue path, use `#!/usr/bin/env bash` and not `#!/bin/bash` (it could be elsewhere on BSD or Solaris)
* Don't assume absolute path, use <code>#!/usr/bin/env bash</code> and not <code>#!/bin/bash</code> (it could be elsewhere on BSD or Solaris)
* Use `sh` as must as possible, try to avoid `bash`, document exceptions rationale in your commits
* Use `sh` as must as possible, try to avoid <code>bash</code>, document exceptions rationale in your commits


Whitespaces:
Whitespaces:
Line 36: Line 92:
* Filename should start by a verb if it performs an action
* Filename should start by a verb if it performs an action
* Don't use .sh extensions (sometimes you'll see them on Phabricator pastes' titles, but it has been added there, so Phab knows shell syntax highlighting should be used)
* Don't use .sh extensions (sometimes you'll see them on Phabricator pastes' titles, but it has been added there, so Phab knows shell syntax highlighting should be used)
** '''Tip.''' You can use .sh in src/ to help linters, but then provide a Makefile to install it under correct name without extension
== Makefile ==
UNIX agnosticism:
* Test your makefile against BSD make, and document in README.md to use GNU Makefile (gmake) when it's not convenient to keep compatibility
Presentation:
* Create a block with the general targets, then sections with your targets organized by categories/goals/parts
Tip:
* It's possible to provision BSDmakefile and GNUmakefile when UNIX agnosticism doesn't work.
== Structured data formats (YAML, JSON, XML) ==
The number of spaces depend if the format is usually heavily hierarchized or not:
* 2 spaces for JSON and YAML
* 4 spaces for XML, TOML and other configuration files
== Utilities ==
The https://github.com/nasqueron/codestyle repository contains resource to help to respect code convention, like a phpcs ruleset, a configuration ready for PhpStorm, IntelliJ and other JetBrains editors, or a clang-format configuration file.
== Troubleshoot ==
=== Fix indent issues ===
The <code>expand</code> utility converts tabs into spaces, while <code>unexpand</code> convert spaces into tabs.
Switch a file from tab indent to 4 spaces indent:
    $ expand -t 4 foo.sh > a
    $ cat a > foo.sh
    $ rm a
(Avoid <code>mv</code> for shell scripts as your foo.sh has probably a 755 chmod, and a will probably have a 644 chmod, assuming 022 as umask)
Switch a file indent with 2 spaces to 4 spaces:
    $ unexpand -t 2 JetBrains/php-codestyle.xml > a
    $ expand -t 4 a > JetBrains/php-codestyle.xml
This last technique can be used in batch [https://gist.github.com/dereckson/80a746b408c0cf0b688a09db31d5c881 with this reindent script]:
    $ git ls-files | xargs -n1 reindent 2 4


[[Category:Reference]]
[[Category:Reference]]
[[Category:Contributor guide]]

Latest revision as of 21:37, 24 October 2024

All languages

  • Don't use more complicated constructs like ternary operators
  • Keep functions short and simple.
  • Define explicitly methods visibility, as several languages have different default values (e.g. private for C# class members, public for PHP methods)
  • Comments to document a method are written at the singular 3rd person (we seem to have moved to infinitive recently, we need to take a decision here)

C

If you use ClangFormat, a .clang-format file is available.

JavaScript

The following conventions are used:

  • K&R, 1TBS variant, including for functions
  • 4 spaces as indent
  • Use modern JavaScript idioms like const and let instead of var
  • Consider to use async code for events-driven development, especially for servers

PHP

The following conventions are used:

  • K&R, 1TBS variant, including for functions
  • 4 spaces as indent
  • The keywords true, false and null must be in lower case.
  • Arrays use short syntax
  • Array elements ends with a comma
  • Functions, methods and class names use camel case

If you use PhpStorm or another JetBrains IDE, you can import JetBrains/php-codestyle.xml from the codestyle repository as a code style (Settings or Default Settings > Editor > Code Style > PHP > click on the wheel icon > Import Scheme > Intellij IDEA codestyle XML).

If you want to lint a project with phpcs, you can require the Composer package nasqueron/codestyle and use the following phpcs.xml standard file:

<?xml version="1.0"?>
<ruleset>
    <rule ref="vendor/nasqueron/codestyle/CodeSniffer" />
    <file>.</file>
    <exclude-pattern>\.git/</exclude-pattern>
    <exclude-pattern>vendor/</exclude-pattern>
</ruleset>

Python

2023. We follow black style, so use black utility (pip install black). As such, you need to configure Flake8 to ignore rule E203.

2015. We follow PEP-8.

Rust

2023. Automated codestyle (black in Python, clang-format in Rust) seems preferable. As such, a style compatible with rustfmt is needed to be able to format using cargo fmt. You can add to your project rust/rustfmt.toml in codestyle to configure it.

2015. We followed "Rust default style", described at https://aturon.github.io/. It's mainly a K&R, 1TBS variant.

Use trailing comma for elements in every struct/impl/etc.

Salt

Style

Whitespaces:

  • Indent with two spaces
  • YAML lists use indented bullets
id:
  method:
    - somekey: value
    - otherkey: value

Tips

Files provisioned
  • When you ask to download a file remotely, you need a source hash, pick SHA256 as algo
  • Each file provisioned from the Salt repository must contains an header explaining the fact, with the full path in the rOPS repo
BSD and Linux distros compatible states
  • populate the map.jinja file with OS logic (e.g. `dirs` for /etc vs /usr/local/etc)
  • when you've a specific set of tasks to do for one OS/distro, it's acceptable to enclose it in a state by an if block

Vocabulary

Domain names
To refer to the fully qualified domain name sub.domain.tld, use fqdn. To split the domains in part, use domain and subdomain. This is important to understand a state without having to refer to the associated pillar to disambig domain.

Shell scripts

UNIX agnosticism:

  • Don't assume absolute path, use #!/usr/bin/env bash and not #!/bin/bash (it could be elsewhere on BSD or Solaris)
  • Use `sh` as must as possible, try to avoid bash, document exceptions rationale in your commits

Whitespaces:

  • One whitespace line between shebang and actual content
  • Indent with tabulations

File names:

  • We use hyphens (-) as separators, not underscores or camelcase.
  • Filename should start by a verb if it performs an action
  • Don't use .sh extensions (sometimes you'll see them on Phabricator pastes' titles, but it has been added there, so Phab knows shell syntax highlighting should be used)
    • Tip. You can use .sh in src/ to help linters, but then provide a Makefile to install it under correct name without extension

Makefile

UNIX agnosticism:

  • Test your makefile against BSD make, and document in README.md to use GNU Makefile (gmake) when it's not convenient to keep compatibility

Presentation:

  • Create a block with the general targets, then sections with your targets organized by categories/goals/parts

Tip:

  • It's possible to provision BSDmakefile and GNUmakefile when UNIX agnosticism doesn't work.

Structured data formats (YAML, JSON, XML)

The number of spaces depend if the format is usually heavily hierarchized or not:

  • 2 spaces for JSON and YAML
  • 4 spaces for XML, TOML and other configuration files

Utilities

The https://github.com/nasqueron/codestyle repository contains resource to help to respect code convention, like a phpcs ruleset, a configuration ready for PhpStorm, IntelliJ and other JetBrains editors, or a clang-format configuration file.

Troubleshoot

Fix indent issues

The expand utility converts tabs into spaces, while unexpand convert spaces into tabs.

Switch a file from tab indent to 4 spaces indent:

   $ expand -t 4 foo.sh > a
   $ cat a > foo.sh
   $ rm a

(Avoid mv for shell scripts as your foo.sh has probably a 755 chmod, and a will probably have a 644 chmod, assuming 022 as umask)

Switch a file indent with 2 spaces to 4 spaces:

   $ unexpand -t 2 JetBrains/php-codestyle.xml > a
   $ expand -t 4 a > JetBrains/php-codestyle.xml

This last technique can be used in batch with this reindent script:

   $ git ls-files | xargs -n1 reindent 2 4