5 ms·
The list of rules covered can be found in the book description on the purchase links, like: https://bookshop.org/p/books/the-rules-of-programming-how-to-write-b
by avg_dev 2y ago
The list of rules covered can be found in the book description on the purchase links, like: https://bookshop.org/p/books/the-rules-of-programming-how-to-write-better-code-chris-zimmerman/18606206?ean=9781098133115 https://bookshop.org/p/books/the-rules-of-programming-how-to...
- lukan 2y ago"The rules in this book include: As simple as possible, but no simpler Let your code tell its own story Localize complexity Generalization takes three examples Work backward from your result, not forward from your code The first lesson of optimization is don't optimize A good name is the best documentation Bugs are contagious Eliminate failure cases Code that isn't running doesn't work Sometimes you just need to hammer the nails " Sounds quite solid - as guidelines. My only rule for programming is, that the result is correct and usable.
- XorNot 2y agoMy arbitrary rule from recent experience is this: you do not need to lint your JSON by compiling and then running a Serde-based Rust application as part of your CI/CD pipeline for every single commit, when the project is entirely Python and Ansible for systems deployment.
- WillAdams 2y agoSounds quite a bit like the principles put forward in Ousterhout's _A Philosophy of Software Design_ https://www.goodreads.com/book/show/39996759-a-philosophy-of-software-design https://www.goodreads.com/book/show/39996759-a-philosophy-of... https://web.stanford.edu/~ouster/cgi-bin/book.php https://web.stanford.edu/~ouster/cgi-bin/book.php which has seen a fair bit of discussion here: https://news.ycombinator.com/item?id=17779953 https://news.ycombinator.com/item?id=17779953 https://news.ycombinator.com/item?id=31248641 https://news.ycombinator.com/item?id=31248641 https://news.ycombinator.com/item?id=37975558 https://news.ycombinator.com/item?id=37975558 https://news.ycombinator.com/item?id=17906662 https://news.ycombinator.com/item?id=17906662 and there's a video: https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY (which has also been discussed) I read it when I got stuck on a recent project, and paused after each chapter to review _all_ of the code (fortunately, it's a fairly small project) and to apply the principles from that chapter to the code, and it was a big help and got me over the hurdle to a working version.
- billforsternz 2y agoA little micro-technique compatible with the "a good name is the best documentation" rule; create temporary well named boolean variables to "document" your branching logic. A toy example; bool in_range = begin<=idx && idx<end; if( in_range ) { do_something(); }