0Pricing
DevOps Bootcamp · Lekcja

Najlepsze praktyki skryptowania i linting

Pozna Pan/Pani konwencje kodowania, komentowanie oraz narzędzia takie jak ShellCheck, aby pisać przejrzyste, czytelne i wolne od błędów skrypty Bash.

Najlepsze praktyki skryptowania i linting to bezpłatna lekcja DevOps Bootcamp na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej DevOps Bootcamp, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs DevOps Bootcamp zawiera 4 lekcji w sumie.

Dlaczego warto stosować dobre praktyki skryptowe?

Pisanie skryptów Bash daje duże możliwości, ale bez dobrych nawyków skrypty mogą stać się trudne do zrozumienia, utrzymania i debugowania.

Dobre praktyki to wytyczne pomagające pisać czysty, niezawodny i czytelny kod. Dzięki nim skrypty są:

  • Łatwiejsze do czytania: zarówno dla Państwa, jak i innych osób.
  • Łatwiejsze w utrzymaniu: prostsze do aktualizowania lub naprawiania.
  • Mniej podatne na błędy: pomagają zapobiegać typowym pomyłkom.
  • Lepsze do współpracy: ujednolicają wygląd i działanie kodu.

Komentarze zwiększające przejrzystość

Komentarze mają kluczowe znaczenie, ponieważ wyjaśniają, dlaczego kod coś robi, a nie tylko co robi. Są notatkami dla Państwa w przyszłości lub dla innych programistów.

Komentarzy należy używać do:

  • opisania na początku ogólnego przeznaczenia skryptu;
  • wyjaśnienia złożonej logiki lub trudnych fragmentów;
  • udokumentowania funkcji: ich przeznaczenia, argumentów i wartości zwracanych.

Komentarz należy rozpocząć symbolem # (hash).

#!/bin/bash
# This script demonstrates commenting best practices.
# Author: CoddyKit
# Date: 2023-10-27

# Function: greet_user
# Description: Prints a greeting message to the console.
# Arguments:
#   $1 - The name of the user to greet.
greet_user() {
  local name="$1" # Store the first argument in a local variable.
  echo "Hello, ${name}!" # Output the greeting message.
}

# Main script execution starts here.
echo "Script execution started."
greet_user "CoddyKit Learner" # Call the function with a specific name.
echo "Script execution finished."

Czytelne zasady nazewnictwa

Znaczące nazwy ułatwiają zrozumienie skryptu. Należy unikać zmiennych o nazwach jednoliterowych, chyba że są to typowe liczniki pętli (takie jak i lub j).

Ogólne konwencje:

  • Zmienne: używaj opisowych nazw (np. user_name, log_file). Używaj UPPERCASE dla zmiennych środowiskowych lub stałych globalnych. Używaj lowercase_with_underscores dla lokalnych zmiennych skryptu.
  • Funkcje: używaj lowercase_with_underscores, często zaczynając nazwę od czasownika (np. process_data, check_status).
  • Skrypty: używaj lowercase_with_hyphens (np. backup-script.sh).

Spójne formatowanie i wcięcia

Spójne formatowanie, takie jak wcięcia i odstępy, znacznie poprawia czytelność. Proszę wyobrazić sobie czytanie książki z niespójnymi wcięciami akapitów!

Najważniejsze zasady:

  • Używaj 2 lub 4 spacji do wcięć (tabulatory są często odradzane).
  • Nie twórz zbyt długich wierszy (dobrą zasadą w terminalach jest maksymalnie 80 znaków).
  • Używaj pustych wierszy do oddzielania logicznych bloków kodu.
  • W razie potrzeby wyrównuj powiązane elementy.

Spójność jest ważniejsza niż konkretny wybrany styl.

Niezawodność: „set -u” (nounset)

Opcja set -u (lub set -o nounset) pomaga zapobiegać błędom spowodowanym literówkami lub przypadkowo nieustawionymi zmiennymi. Jeśli skrypt spróbuje użyć zmiennej, której nie przypisano wartości, set -u natychmiast zakończy skrypt z błędem.

Pomaga to wcześnie wykrywać błędy i zapobiegać nieoczekiwanemu działaniu w dalszej części skryptu.

Uruchom poniższy kod. Jest skonfigurowany tak, aby zakończyć działanie wcześniej, ponieważ UNSET_NAME nie jest zdefiniowana.

#!/bin/bash
# Demonstrating 'set -u' (nounset)

set -u # Exit if an unset variable is used

MY_GREETING="Hello"
echo "${MY_GREETING}, CoddyKit!"

# This variable is NOT set. With 'set -u', the script will exit here.
echo "Your name is: ${UNSET_NAME}" 

echo "This line will NOT be reached if 'set -u' is active and UNSET_NAME is indeed unset."

Niezawodność: „set -o pipefail”

Podczas przekazywania danych między poleceniami (np. cmd1 | cmd2 | cmd3) Bash zwykle zgłasza tylko status wyjścia ostatniego polecenia w potoku. Oznacza to, że jeśli cmd1 zakończy się niepowodzeniem, ale cmd2 i cmd3 zakończą się powodzeniem, potok może mimo wszystko zgłosić powodzenie!

set -o pipefail zmienia to zachowanie. Jeśli dowolne polecenie w potoku zakończy się niepowodzeniem (zwróci status różny od zera), cały potok otrzyma ten status różny od zera.

Dzięki temu potoki stają się bardziej niezawodne, ponieważ natychmiast sygnalizują niepowodzenie wcześniejszego polecenia.

#!/bin/bash
# Demonstrating 'set -o pipefail'

set -o pipefail # Ensures pipe's exit status is the last non-zero command

echo "Running a failing command in a pipe:"
echo "---"

# 'false' command always fails (exit status 1).
# 'cat /dev/null' always succeeds (exit status 0).
# With 'set -o pipefail', the pipe's overall exit status will be 1 from 'false'.
false | cat /dev/null

# This line will only be reached if the pipe above succeeds.
echo "---"
echo "Script finished successfully (this line won't show if pipe failed with set -o pipefail)."

Wprowadzenie do ShellCheck

Nawet przy stosowaniu dobrych praktyk łatwo przeoczyć drobne błędy składni lub typowe pułapki. Właśnie tutaj przydaje się ShellCheck!

ShellCheck to narzędzie do analizy statycznej (tzw. „linter”) skryptów powłoki. Odczytuje skrypt i wskazuje:

  • błędy składni;
  • typowe błędy początkujących;
  • subtelne problemy semantyczne;
  • problemy z przenośnością między różnymi powłokami.

Podaje pomocne sugestie, często wraz z odsyłaczami do bardziej szczegółowych wyjaśnień.

ShellCheck w działaniu: niepoprawny skrypt

Przyjrzyjmy się skryptowi zawierającemu kilka typowych problemów. Mogą one nie spowodować natychmiastowego awarii skryptu, ale stanowią złe praktyki lub potencjalne błędy.

Załóżmy, że ten skrypt zapisano jako bad_script.sh. Aby uruchomić na nim ShellCheck, należy wpisać: shellcheck bad_script.sh

Spróbuj znaleźć problemy, zanim uruchomisz ShellCheck!

#!/bin/bash
# A script with some common issues

MY_NAME=coddykit # Variable assignment needs no space, but quoting is good for values
echo "Hello $MY_NAME!" # Missing quotes around variable expansion

if [ $1 = "admin" ]; then # Missing quotes around $1
  echo "Welcome, administrator."
fi

# A simple loop with potential issues
for file in *.txt; do # Unquoted glob could expand to multiple arguments
  echo File: $file # Missing quotes around $file
done

Usuwanie ostrzeżeń ShellCheck

ShellCheck wyświetliłby wynik taki jak: SC2086: Double quotes missing around "$MY_NAME". Często podaje konkretny kod (np. SC2086), który można wyszukać, aby uzyskać więcej informacji.

Oto poprzedni skrypt poprawiony zgodnie z zaleceniami ShellCheck oraz ogólnymi dobrymi praktykami:

Zwróć uwagę na użycie cudzysłowów podwójnych "" wokół rozwinięć zmiennych i podstawień poleceń, aby zapobiec dzieleniu słów i rozwijaniu wzorców glob, które często powodują błędy.

#!/bin/bash
# A script with issues fixed by ShellCheck

MY_NAME="CoddyKit" # Quote variable assignment values
echo "Hello ${MY_NAME}!" # Always quote variable expansions

if [ "$1" = "admin" ]; then # Quote positional parameters like $1
  echo "Welcome, administrator."
fi

# A simple loop with corrected quoting
for file in *.txt; do 
  echo "File: ${file}" # Quote variable expansions, especially in loops
done

Sprawdzanie dobrych praktyk

Które z poniższych praktyk uznaje się za dobre podczas pisania skryptów Bash?

Podsumowanie: profesjonalne skrypty

Gratulacje! Wiesz już, jak podnosić jakość skryptów Bash z poziomu działających do profesjonalnych.

Omówiliśmy:

  • znaczenie dobrych praktyk dla czytelności i łatwości utrzymania kodu;
  • używanie komentarzy i konwencji nazewniczych dla większej przejrzystości;
  • zwiększanie niezawodności skryptów za pomocą set -u i set -o pipefail;
  • możliwości narzędzia ShellCheck, które automatycznie wykrywa problemy i pomaga ulepszać kod.

Stosując te zasady, będziesz pisać bardziej niezawodne, zrozumiałe i łatwiejsze we współpracy skrypty Bash. Ćwicz dalej!

Często zadawane pytania

Czy lekcja „Najlepsze praktyki skryptowania i linting” jest bezpłatna?

Tak — pełny tekst „Najlepsze praktyki skryptowania i linting” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu DevOps Bootcamp, przejdź na CoddyKit PRO. Kurs DevOps Bootcamp zawiera 4 lekcji w sumie.

Co nauczysz się w „Najlepsze praktyki skryptowania i linting”?

Pozna Pan/Pani konwencje kodowania, komentowanie oraz narzędzia takie jak ShellCheck, aby pisać przejrzyste, czytelne i wolne od błędów skrypty Bash. Ćwiczysz DevOps Bootcamp z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć DevOps Bootcamp?

Nie wymagamy żadnego doświadczenia. DevOps Bootcamp w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Najlepsze praktyki skryptowania i linting”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji DevOps Bootcamp?

Tak. Każda lekcja DevOps Bootcamp zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Debugowanie skryptów Bash (set -x, trap)
  2. Obsługa błędów i status wyjścia
  3. Najlepsze praktyki skryptowania i linting
  4. Testowanie skryptów Bash za pomocą Bats
← Powrót do DevOps Bootcamp