This philosophy-of-programming guide presents a unique and entertaining take on how to think about programming. A collection of 21 pragmatic rules, each presented in a stand-alone chapter, captures the essential wisdom that every freshly minted programmer needs to know and provides thought-provoking insights for more seasoned programmers.
Author Chris Zimmerman, cofounder of the video game studio Sucker Punch Productions, teaches basic truths of programming by wrapping them in memorable aphorisms and driving them home with examples drawn from real code. This practical guide also helps managers looking for ways to train new team members.
“Młody programista szybko sobie uzmysławia, że opanowanie języka programowania nie oznacza umiejętności pisania dobrego kodu. Zanim je opanuje, trzeba spędzić wiele bezsensownych nocy na próbach usunięcia błędów czy rozwiązania innych problemów. Programowanie jest po prostu trudną sztuką. Czy istnieje sposób, aby choć trochę ją ułatwić?" - Paul Daugherty _____________ Oczywiście, że istnieje! Wystarczy trzymać się odpowiednich zasad, ustawić sobie reguły programowania. O nich właśnie pisze Chris Zimmerman w swojej książce, o, jakże pięknym tytule: “Reguły programowania. Jak pisać lepszy kod”.
Książka jest odpowiednia na każdym etapie programistycznej przygody i dla każdego programisty. Jest latarnią na morzu kodu - dzięki treścią w niej zawartych można odnaleźć drogę do zrozumienia i poprawności napisanych linijek. 21 zasad, które są wytłumaczone jasno i na konkretnych przykładach. Aż chce się je po przeczytaniu wypróbować! _____________ Przeczytaj Reguły programowania, jeśli:
💕 jesteś początkującym programistą i chcesz rozumieć kod 💕 pracujesz w zespole i nie chcesz tracić czasu na dokładne analizowanie każdej linijki 💕 nie wiesz co możesz ulepszyć w swoim sposobie pisania 💕 chcesz unikać błędów 💕 masz problem z pisaniem zbyt długich i zawiłych skryptów 💕 nie wiesz jak tłumaczyć kod, który właśnie napisałeś → ile bym dała za wiedzę z tej książki pół roku temu!
I participated in a game jam while I was about halfway through reading this book, and I wouldn’t call that a situation where I’m trying to write *good* code per se (more like, something that works and can be created as quickly as possible that I’ll never look at again), but with a few of these rules fresh in mind, I got to be extra aware of just how bad the code I was writing would be if it was any other situation. Thaaanks…
In all seriousness, having these rules all laid out detailing generally good programming practices is really helpful. As a programmer, I find it very easy to overthink and overcomplicate tasks. These rules touch on a lot of important fundamental skills and provide advice on how to handle very common issues I expect to come across when working with a big codebase that’s frequently updated by many other people. The book also provides a great perspective for me, as someone early in my career, for what I can expect to learn and practice on a software engineering team, and how effective it is to make sure the team uses consistent style, so you can read everyone’s code no differently than if it were your own. I especially appreciate the provided code examples that come from years of experience working on a game engine and fixing bugs related to complex game states. This was a very worthwhile read.
This is book from one of the famous game developers, authors of Ghost of Tsushima. You all know Chris Zimmerman, right? Anyway, this is not something that I usually read. But I love the idea of rules for the programming and always like to hear other opinions. Overall, book about authors advice on how to solve most common programming problems. What I like: idea how to find bugs and write clean code, code optimisations techniques, comments and naming. Pretty much usual stuff, but I like lots of code (even in C++) showing that. Lots of examples. I feel like he's good at coding. Tho, there were few very controversial ideas, like for example not everyone needs testing or can adopt it. Not just automation, but any tests. This is weird to me. Same for CICD or any kind of automation. This is impossible to skip that, right? But then I realised that author is developing totally different things than I usually do. And so, instead of focusing on being able to change code for any business needs, delivery, etc, game development focuses on totally different things. So, once again, it was fun to read and argue against.
For a book about programming, I'd have to say it was pretty dang good. I thought the writing was done well, and the author made things entertaining to read. I appreciated that it was very clear that these rules may not work for what/how you program, but some of them definitely are. Now, to tackle some of the programming drudgery tasks that I've been putting off for too long.