6 ms·
The Rules of Programming (2023)
- joaquincabezas 2y agoThe first rule of programming is you do not talk about programming
- 00kevn 2y agoThat’s Fight Club
- Vordimous 2y agoOr book club
- antony_pond 2y agolol
- deleted 2y ago[deleted]
- avg_dev 2y agoThe 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(); }
- zabzonk 2y agoThis is an ad for a book.
- markrages 2y agoThe Amazon preview included a page advocating for systems Hungarian in naming variables. I am no longer interested in the book.
- rurban 2y agoHe was a Microsoft manager, so this insanity is expected.
- crdrost 2y agoIf we mix Polish and Hungarian notation we get Buda notation: flowingSequence :: (a -> [x]) -> ((a, x) -> y) -> (a -> a -> a) -> [a] -> [y] flowingSequence = lyla''aaa'ypax_lxa where lyla''aaa'ypax_lxa lxa ypax aaa la = map ypax $ concatMap (lpax_palx . palx_a) la2 where la2 = scanl1 aaa la palx_a a = (a, lxa a) lpax_palx (a, lx) = map pax_x lx where pax_x x = (a, x) (The Treaty of Buda was a political maneuver that briefly created a united monarchy for Hungary and Poland in the 1300s.)
- veltas 2y agoWhere is this? I don't see this advocation, and the code examples don't have it.
- nuancebydefault 2y agoAs programmers we are ingrained to look further than the problem at hand. We try to see the bigger picture, solve problems in holistic ways if possible. Often this can lead to over-engineering, creating more corner cases and ambiguity in requirements and reduction of test coverage. That is a trap to lok out for. On the other hand it also can lead to better understanding of the problem space, increase understandability, and less need for later refactoring. Just stating, 'don't look further than the problem you are required to solve' is not an excellent general rule.
- gherkinnn 2y agoThe trick is not to stop at the birds-eye view but to see that one small change that is actually required from up high and dive back down.
- Nevermark 2y agoI don’t think it makes sense to not think of generality options. Often that helps us see a problem in more ways. Come at it from different directions. Generalizing mentally is map discovery, But when it comes to implementation, any code that is there to enable unused generality is unused and unnecessary code. Any unused freedom of interface increases the chance of unintentional misuse or sleeper bugs. The number of ways unnecessary code or loose constraints can be unhelpful is unlimited. When it comes to optimizing, testing, maintaining, it is optimal to have the narrowest mission possible. — The exception is when designing a platform or library, with open ended reuse. Then value can genuinely be increased with greater applicability. Then there will be generality vs. focused tradeoffs whose resolution will be very context dependent. On the subject matter and its potential market/users.
- switchbak 2y agoYeah, it's a real challenge to come up with low resolution rules/heuristics. That becomes much harder when you're tailoring your message to different communities / expertise levels. I agree with you, but I also get where the author is coming from. Sometimes simple guard rails for new devs is a lot better than ultra detailed nuance that leaves them without a simple path forward. In my experience I've witness horrible examples of both extremes. Overgeneralized yet poor solutions, and (often duplicated) hyper specific solutions. Both typically from less experienced folks. I think more communication and mentoring would really have helped more there.
- deleted 2y ago[deleted]
- maxverse 2y agoThere are several books that commonly get recommended for all around general programming knowledge (Pragmatic Programmer, A Philosophy Of Software Design, etc) Curious how this is any different!
- vismit2000 2y agoPhilosophy of Software Design had the most impact on my general naming and structuring. Just some really great advice in a sub 200 page book
- revskill 2y agoRule 1: easy to add, easier to delete.
- liendolucas 2y agoI believe this is the type of book that I'd like to skim to see what it has to offer rather than just blindly buy it. This is how interpret some of those points: * As simple as possible, but no simpler -> Don't get into fancy stuff like e.g: design patterns just because you learnt or know them? Same for other techniques depending your language and facilities? Don't use things just for using them. * Let your code tell its own story -> Use verbs for functions and methods, nouns for variables and classes so code is understood with minimum effort as is being read? * Generalization takes three examples -> Sure, first you write a solution, then copy paste it if needed elsewhere as you didn't expect to be reused, third time make an abstraction (function(s), method(s), etc) as it popped up once again? * A good name is the best documentation -> Picking reasonably good names for all kind of identifiers will make code self-document and understand? * Sometimes you just need to hammer the nails -> Sometimes you need to be pragmatic and get a thing done, maybe not in the best possible way? * Code that isn't running doesn't work -> Remove all commented/dead code from a codebase as not only running but might also generate confusion to other people? I do not want to diminish the content of the book in any way nor sound arrogant, but in the past I've seen similar titles and they weren't offering that much to what I already knew at the time.
- nox101 2y agoI would say > Code that isn't running doesn't work would be > Code that isn't tested doesn't work Testing is running though but that's not the same as eliminating dead code. If you're writing a library/API, you might not personally use the code or hit the edge cases but other users will. If they aren't tested they don't work is my experience.
- vinay_ys 2y agoAny modern software design has to meet these 3-4 key aspects: 1. Make the software scalable w.r.t machines. 2. Make the software scalable w.r.t humans. 3. Make the software maintainable over time. 4. Make the software reusable to reduce startup costs. Motivated by these, we make a lot of choices: 1. decompose a large complex problem into smaller, isolated, modular problems that can be worked on by different small teams, and run on different servers with inter-server communication. 2. organize code along with its documentation for easy understanding, readability and modifiability over time by same developers and different developers. 3. organize reusable and independently upgradable parts of the code for ease of upgrade with stable interfaces and stable test suites. 4. maintain the build/package/deploy toolchains for ease of underlying hardware and operating systems upgrades without affecting all of the code. 5. reuse is the only way to reduce costs – both time and effort – for anything. thinking carefully and setting up for reuse of services, systems, libraries, toolchains, processes, practices etc are critical to any large successful software project. These are general rules for normal times. But there are inflection points when it is profitable to violate these rules. Things that distort the cost/benefit tradeoffs and make it profitable to violate these rules: 1. When tech ecosystem is rapidly evolving and toolchains and libraries ecosystem isn't mature. 2. When time to market is super critical and if successful we will have more than enough money to deal with these problems later, and if we are late even with good software we would have failed and shut shop. 3. When we can't hire talented skilled engineers and still it is worthwhile to win in the short-term. With these rules and violations, you can get stuck in an early local optima. A culture of continuous safe refactors is a super-power that can make you immune to it. Ossification of any kind is bad.
- keithalewis 2y agoWhen I worked at Bloomberg their first coding guideline was "Don't sweat the small stuff." I was mystified by that when I first read it. Then I sat in meetings where someone would drone on about how clever they thought their code was until someone asked "Is this small stuff?" It would shut them up so we could move on to more important matters.
- alfonsovng 2y agoIt's important to remark that the organization "Girls Who Code" gets all the royalties from this book.
- gatane 2y agoTo break the rules, thou must know them first.
- lincpa 2y ago[dead]
- shahzaibmushtaq 2y agoMy simple rule of programming is to code the worst-possible solution at the beginning and improve from there step by step.
- ajorgensen 2y ago1000%. The number of times I’ve tried to go straight to the correct well factored abstraction and it worked out are countable on one hand. This is one of those pieces of advise that I know to be true yet it takes continuous effort to enact.
- shahzaibmushtaq 2y agoExactly. I weakened my problem-solving skills in chasing the best-possible solution every time on the first try.
- jwxz 2y ago> code the worst-possible solution This is also a great way to stop procrastinating and start projects. Relevant quote: "He who has begun has half done. Dare to be wise; begin!" - Horace
- deleted 2y ago[deleted]