Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.gitlab.com/development/contributing/style_guides/ below:

Development style guides | GitLab Docs

We use EditorConfig to automatically apply certain styling standards before files are saved locally. Some editors and IDEs honor the .editorconfig settings automatically by default.

If your editor or IDE does not automatically support .editorconfig, we suggest investigating to see if a plugin exists. For example, a plugin for vim.

Lefthook is a Git hooks manager that allows custom logic to be executed prior to Git committing or pushing. GitLab comes with Lefthook configuration (lefthook.yml), but it must be installed.

We have a lefthook.yml checked in but it is ignored until Lefthook is installed.

We were using Overcommit prior to Lefthook, so you may want to uninstall it first with overcommit --uninstall.

1. You can install lefthook in different ways. If you do not choose to install it globally (for example, via Homebrew or package managers), and only want to use it for the GitLab project, you can install the Ruby gem via:

2. Install Lefthook managed Git hooks:

   # If installed globally
   lefthook install
   # Or if installed via ruby gem
   bundle exec lefthook install

3. Test Lefthook is working by running the Lefthook pre-push Git hook:

   # If installed globally
   lefthook run pre-push
   # Or if installed via ruby gem
   bundle exec lefthook run pre-push

This should return the Lefthook version and the list of executable commands with output.

Lefthook is configured with a combination of:

• Project configuration in lefthook.yml.
• Any local configuration.

We have a custom lefthook target to run all the linters with auto-fix capabilities, but just on the files which changed in your branch.

# If installed globally
lefthook run auto-fix
# Or if installed via ruby gem
bundle exec lefthook run auto-fix

To disable Lefthook temporarily, you can set the LEFTHOOK environment variable to 0. For instance:

You can run the pre-commit, pre-push, and auto-fix hooks manually. For example:

bundle exec lefthook run pre-push

For more information, check out Lefthook documentation.

To skip some checks based on tags when pushing, you can set the LEFTHOOK_EXCLUDE environment variable. For instance:

LEFTHOOK_EXCLUDE=frontend,documentation git push ...

As an alternative, you can create lefthook-local.yml with this structure:

pre-push:
  exclude_tags:
    - frontend
    - documentation

For more information, check out Lefthook documentation.

To skip or enable a check based on its name when pushing, you can add skip: true or skip: false to the lefthook-local.yml section for that hook. For instance, you might want to enable the gettext check to detect issues with locale/gitlab.pot:

pre-push:
  commands:
    gettext:
      skip: false

For more information, check out Lefthook documentation Skipping commands section.

See the dedicated Database Migrations Style Guide.

See the dedicated JS Style Guide.

See the dedicated SCSS Style Guide.

See the dedicated Ruby Style Guide.

See the dedicated Go standards and style guidelines.

See the dedicated Guidelines for shell commands in the GitLab codebase.

See the dedicated Shell scripting standards and style guidelines.

See the dedicated npmjs package publishing guide.

We’re following Ciro Santilli’s Markdown Style Guide.

See the dedicated Documentation Style Guide.

Good practice examples demonstrate encouraged ways of writing code while comparing with examples of practices to avoid. These examples are labeled as “Bad” or “Good”. In GitLab development guidelines, when presenting the cases, it’s recommended to follow a “first-bad-then-good” strategy. First demonstrate the “Bad” practice (how things could be done, which is often still working code), and then how things should be done better, using a “Good” example. This is typically an improved example of the same code.

Consider the following guidelines when offering examples:

• First, offer the “Bad” example, and then the “Good” one.
• When only one bad case and one good case is given, use the same code block.
• When more than one bad case or one good case is offered, use separated code blocks for each. With many examples being presented, a clear separation helps the reader to go directly to the good part. Consider offering an explanation (for example, a comment, or a link to a resource) on why something is bad practice.
• Better and best cases can be considered part of the good cases’ code block. In the same code block, precede each with comments: # Better and # Best.

Although the bad-then-good approach is acceptable for the GitLab development guidelines, do not use it for user documentation. For user documentation, use Do and Don’t. For examples, see the Pajamas Design System.

See the dedicated Python Development Guidelines.

Code should be written in US English.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4