Chapter 11. Developing Your Style Guide

The overarching theme of this book is writing idiomatic, yet readable, bash code in a consistent style, and we hope we’ve provided the tools you need to do that. Style is just another way to say “how we write things.” Find some style guidelines, write ’em down, and stick to ’em. We’ve covered a number of important style considerations in this book, and there are some other guidelines we’d like to mention as well, things to keep in mind when designing systems and writing code. You can use this chapter as a starting point for your own style guide or just adopt it as is if you like it. The Appendix is the same material without the talking points, to use as a “cheat sheet,” and you can get the Markdown or HTML code from this book’s GitHub page.

Keep the following high-level principles in mind:

  • Above all: KISS—Keep It Simple, Stupid! Complexity is the enemy of security,1 but it’s also the enemy of readability and understanding. Sure, modern systems and circumstances are complex, so try hard not to make it any worse than it already is.

  • The corollary, as Brian Kernighan famously said, is that debugging is twice as hard as writing the code in the first place, so if your code is as clever as you can make it, you are—by definition—not smart enough to debug it.

  • Try not to reinvent the wheel. Whatever you are trying to do has probably been done before, and there’s likely a tool or library for it. If that tool is already ...

Get bash Idioms now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.