Jakie są przydatne metody String i warianty z wykrzyknikiem (!)?

Question

Accepted Answer

Stringi w Ruby mają bogaty zestaw metod do manipulacji, a wiele z nich występuje w dwóch formach: zwykła wersja (zwraca **nowy** string) i wersja z **wykrzyknikiem (`!`)** (modyfikuje string **w miejscu**, mutując oryginał). Zrozumienie tej różnicy jest ważne dla poprawności i unikania błędów.

## Popularne metody string

```ruby
"hello".upcase           # "HELLO"
"HELLO".downcase          # "hello"
"  hi  ".strip             # "hi" — remove surrounding whitespace
"hello".reverse           # "olleh"
"hello".length            # 5
"hello world".split(" ")  # ["hello", "world"]
["a", "b"].join("-")       # "a-b"
"hello".sub("l", "L")      # "heLlo" — replace FIRST
"hello".gsub("l", "L")     # "heLLo" — replace ALL (global)
"hello".include?("ell")    # true
"hello".start_with?("he")  # true
"hello".chars             # ["h", "e", "l", "l", "o"]
"42".to_i; "3.14".to_f      # convert to number
"Hi #{name}"               # interpolation
```

## Kluczowa różnica wykrzyknika (!): mutacja w miejscu

```ruby
str = "hello"

# normal version — returns a NEW string, original UNCHANGED
upper = str.upcase        # upper = "HELLO", but str is STILL "hello"
puts str                  # "hello" — unchanged

# BANG version — modifies the original IN PLACE (mutates it)
str.upcase!               # str is NOW "HELLO" — the original changed!
puts str                  # "HELLO"
```

Wersje z **`!` (wykrzyknikiem) mutują oryginalny string w miejscu**, podczas gdy wersje bez wykrzyknika zwracają nowy string i pozostawiają oryginalny niezmieniony. To jest krytyczna różnica — użycie `upcase!` zamiast `upcase` (lub na odwrót) zmienia, czy oryginalny string jest modyfikowany, co może spowodować subtelne błędy.

## Pułapka wykrzyknika: zwrot nil gdy nie ma zmian

```ruby
"hello".upcase!     # "HELLO"
"HELLO".upcase!     # nil! — bang methods return nil if NOTHING changed
# → don't chain off a bang method's return value carelessly
str.strip!&.upcase  # be careful — strip! returns nil if there was nothing to strip
```

Subtelna pułapka: metody z wykrzyknikiem zwracają **`nil`** jeśli nie dokonały żadnych zmian — więc łańcuchowanie ich wartości zwracanej może się nie powiść.

## Dlaczego to ważne

Manipulacja stringami jest wszechobecna w programowaniu, więc znajomość bogatego zestawu metod string w Ruby'ego to przydatna wiedza na co dzień — ale najważniejszy punkt to zrozumienie **różnicy między wykrzyknikiem (`!`) a jego brakiem**, która jest zarówno konwencją nazewnictwa Ruby'ego, jak i częstym źródłem błędów.

Wersja bez wykrzyknika zwraca **nowy** string (pozostawiając oryginalny niezmieniony), podczas gdy **wersja z wykrzyknikiem mutuje oryginalny string w miejscu** — i mylenie ich zmienia, czy oryginalny obiekt jest modyfikowany, co powoduje subtelne, trudne do debugowania błędy (np. oczekując że oryginalny pozostanie niezmieniony, ale użycie `upcase!` go mutuje, lub oczekując mutacji, ale użycie `upcase` pozostawia oryginalny nietkniętym).

Ponieważ stringi w Ruby'ego są mutowalne i wiele metod ma obie formy, zrozumienie tej różnicy jest ważne dla poprawności — wiedza, że `!` typowo oznacza "modyfikuje w miejscu / jest niebezpieczną wersją" (konwencja rozciągająca się poza stringi na inne metody Ruby takie jak `map!`, `sort!`) pozwala przewidzieć i kontrolować zachowanie mutacji.

Dodatkowa **pułapka**, że metody z wykrzyknikiem zwracają `nil` gdy nie dokonają zmian (co może przerwać łańcuchowanie metod) jest również warta poznania.

Zrozumienie przydatnych metod string w Ruby'ego i zwłaszcza **różnicy mutacji między wykrzyknikiem a jego brakiem** (fundamentalna konwencja Ruby'ego wpływająca na to, czy oryginalny jest modyfikowany) jest ważne dla pisania poprawnego Ruby'ego, który bezpiecznie obsługuje stringi — to częste źródło błędów mutacji, a konwencja `!` jest fundamentalnym idiomem Ruby'ego, który odzwierciedla zrozumienie semantyki mutacji w miejscu a semantyki nowych obiektów, co czyni ją praktycznie istotną wiedzą dla stałej pracy ze stringami w Ruby'ego i częstym tematem dotyczącym charakterystycznej, podatnej na błędy konwencji Ruby'ego.