Naming is one of the most difficult and enduring challenges in software engineering, but few of us do it well. This practical and comprehensive book provides a set of principles, rules, and application guidelines for efficiently choosing good names in your code.
These skills can be used throughout your career, and they’re useful for every programming language, technical domain, and experience level. The book incorporates real-world examples to illustrate how to choose good names and avoid bad names.
This book for how to choose good names and avoid bad namesPrinciples to help you remember the general qualities of good namesReal-world examplesGuidelines on the application of these rules and principles, including balancing tradeoffs, renaming best practices, and choosing domain-specific namesTips on how to develop your naming skills throughout your career Changes in the second concisenessRemoval of less important contentGrammatical improvementsFormatting improvements
Nice, brief lecture on the common & widespread linguistic conventions for naming "things" while writing software. No, it's NOT a book on notations (Hungarian, etc.) - it's much more universal & also tech-agnostic. It does answer the question of how to properly name a variable, a function, or a class. But it covers the syntactic aspects, not semantics!
How useful is that? 1. on one hand - very useful because the rules presented here are easily comprehensible & non-controversial 2. on the other hand, I miss A LOT of practical issues when naming was some sort of an issue, e.g., how to name "connecting" tables in many:many relationships; such issues do happen all the time & some guidance here would be more than appreciated - especially for starters 3. personally, I think that the main issues with naming are caused by semantics - the only advice the book presents here is "try Domain Driven Design" - which may be a reasonable direction (Ubiquitous Language!), but DDD is very ethereal itself, so I'd expect some more practical guidance.
Good stuff, but slightly "oversold" (overpromised).
More of a long blog post shaped as a book. Overall pretty pragmatic and prescriptive, but also very subjective and surface level. While I pretty much agree with most of it, I kept thinking "damn there is way more depth to this" or "this requires way more caveats".
Things I liked the most: - mentioning that different languages and ecosystems have different conventions (the book mostly advocates for pythonic style) - nice jab about java people writing enterprise java in any language they try.
Es una muy buena introducción a cómo crear nombres de identificadores que sean útiles, además de la importancia de hacerlos.
Creo que no estoy de acuerdo con algunos de ellos, porque, como todo en el desarrollo de software actualmente, creo que están sujetas a la experiencia de los que están dando el consejo. A pesar de eso, creo que da muy buenos argumentos para poner atención al nombrado de cosas e intenta soportar con buenos razonamientos y ejemplos las cosas que propone.
Al ser una lectura tan corta, la recomendaría a todos los desarrolladores de software que quieran escribir buenos programas.
Short, sweet, and complete. Nice to have a centralized coverage of this ever important topic. Took off one star because it's not all that original, and borrows heavily from other classics in the literature such as Code Complete, Clean Code, Refactoring, the Pragmatic Programmer, and the like. Does provide some good examples and unified guidelines though, so I appreciate the effort.
The author's guidelines, references to studies and relevant books are commendable. However, some sections lacked depth. Overall, this book is a good attempt at addressing naming in software engineering and strategies to mitigate its negative effects.
I feel that only people that already think naming is important will read this book and this book holds no surprises or insights for people that already think naming is important. Preaching to the choir.
A rather straightforward, if not too thorough, review of best practices for naming things while coding. Great on general philosophy, but short on practical steps as the rules of the language and codebase will ultimately provide some influence.