On the other hand, if you examine the given examples, you'll see that very often the "correct" way isn't really longer or harder to type. If you make a point of sticking to the correct way, it will eventually become automatic, and there'll be no fuss and worry. This might end up saving some sorry ass later on.
And having learned the correct way, you'll instantly see it when a script you review is doing something in a way that will eventually bite someone.
There's no downsides to learning and doing things right. Of course it does take some extra time and effort at the start, as everything..
Sure, there are extreme examples that can be really hard to handle portably and safely if you're doing something more complicated (embedded newlines in filenames come to mind). So in the end some corner cutting is often inevitable :-)
> There's no downsides to learning and doing things right.
There is never "no downsides".
For one example, there is "feedback fatigue". It's easy to pick on syntax or "small" semantics during a code review, but that's not nearly as useful as analyzing the big picture. I have been party to many code reviews that involved a dozen nit-picky stylistic comments. The reviewer feels like they did their job, the reviewee feels like they have appeased the reviewer, and so the now style-guide-correct code gets a half-hearted "LGTM" and is merged. That code looks great... And it handles filenames with spaces in them!.. But does the totally wrong thing.
And having learned the correct way, you'll instantly see it when a script you review is doing something in a way that will eventually bite someone.
There's no downsides to learning and doing things right. Of course it does take some extra time and effort at the start, as everything..
Sure, there are extreme examples that can be really hard to handle portably and safely if you're doing something more complicated (embedded newlines in filenames come to mind). So in the end some corner cutting is often inevitable :-)