A good terminal pipeline reads like a short set of instructions. Produce some input. Put it in a useful order. Summarise it. Each step should be easy to explain on its own.
That is easier to achieve by building the command from left to right than by writing the finished line in one attempt.
Use an example you can count by hand
printf '%s\n' pear apple pear
printf '%s\n' pear apple pear | sort
printf '%s\n' pear apple pear | sort | uniq -cThe first line gives three records. The second puts equal records beside one another. The third counts adjacent equal lines, producing one apple and two pears. Sorting matters because uniq groups neighbours; it does not search the entire input for matching lines.
Three lines are enough to see the purpose of every stage. If the result is surprising, remove the final stage and inspect the input it received. The middle of a pipeline is often the best place to find a mistaken assumption.
Output is only half the result
In Bash, a pipeline normally takes its exit status from the last command. That means a command earlier in the line can fail while the final consumer exits successfully. The following example makes the difference visible without touching any files:
bash -c 'false | cat; printf "status=%s\n" "$?"'
# status=0
bash -o pipefail -c 'false | cat; printf "status=%s\n" "$?"'
# status=1Bash's pipefail option makes the status reflect the rightmost command that failed, or zero if all succeeded. The Bash manual's pipeline section documents the details. Check the shell used by a script before relying on a shell-specific option.
Stop before the command becomes a puzzle
A pipeline is useful when the stages are simple and the data format is clear. Once the task needs nested conditions, careful parsing, or several related outputs, a short script may be easier to read.
The goal is a result that can be checked, not the fewest possible characters. Keep the tiny input alongside the command in a note. It is both an explanation and a convenient check the next time the command changes.