"For coders early in their careers who are familiar with an object-oriented language, such as Java or C#"--Back cover.

Practical techniques for writing code that is robust, reliable, and easy for team members to understand and adapt. Summary In Good Code, Bad Code you’ll learn how to: Think about code like an effective software engineer Write functions that read like well-structured sentences Ensure code is reliable and bug free Effectively unit test code Identify code that can cause problems and improve it Write code that is reusable and adaptable to new requirements Improve your medium and long-term productivity Save yourself and your team time The difference between good code or bad code often comes down to how you apply the established practices of the software development community. In Good Code, Bad Code you’ll learn how to boost your productivity and effectiveness with code development insights normally only learned through careful mentorship and hundreds of code reviews. Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. About the technology Software development is a team sport. For an application to succeed, your code needs to be robust and easy for others to understand, maintain, and adapt. Whether you’re working on an enterprise team, contributing to an open source project, or bootstrapping a startup, it pays to know the difference between good code and bad code. About the book Good Code, Bad Code is a clear, practical introduction to writing code that’s a snap to read, apply, and remember. With dozens of instantly-useful techniques, you’ll find coding insights that normally take years of experience to master. In this fast-paced guide, Google software engineer Tom Long teaches you a host of rules to apply, along with advice on when to break them! What's inside Write functions that read like sentences Ensure your code stays bug-free How to sniff out bad code Save time for yourself and your team About the reader For coders early in their careers who are familiar with an object-oriented language, such as Java or C#. About the author Tom Long is a software engineer at Google where he works as a tech lead. Among other tasks, he regularly mentors new software engineers in professional coding best practices. Table of Contents PART 1 IN THEORY 1 Code quality 2 Layers of abstraction 3 Other engineers and code contracts 4 Errors PART 2 IN PRACTICE 5 Make code readable 6 Avoid surprises 7 Make code hard to misuse 8 Make code modular 9 Make code reusable and generalizable PART 3 UNIT TESTING 10 Unit testing principles 11 Unit testing practices

An industry insider explains why there is so much bad software—and why academia doesn't teach programmers what industry wants them to know. Why is software so prone to bugs? So vulnerable to viruses? Why are software products so often delayed, or even canceled? Is software development really hard, or are software developers just not that good at it? In The Problem with Software, Adam Barr examines the proliferation of bad software, explains what causes it, and offers some suggestions on how to improve the situation. For one thing, Barr points out, academia doesn't teach programmers what they actually need to know to do their jobs: how to work in a team to create code that works reliably and can be maintained by somebody other than the original authors. As the size and complexity of commercial software have grown, the gap between academic computer science and industry has widened. It's an open secret that there is little engineering in software engineering, which continues to rely not on codified scientific knowledge but on intuition and experience. Barr, who worked as a programmer for more than twenty years, describes how the industry has evolved, from the era of mainframes and Fortran to today's embrace of the cloud. He explains bugs and why software has so many of them, and why today's interconnected computers offer fertile ground for viruses and worms. The difference between good and bad software can be a single line of code, and Barr includes code to illustrate the consequences of seemingly inconsequential choices by programmers. Looking to the future, Barr writes that the best prospect for improving software engineering is the move to the cloud. When software is a service and not a product, companies will have more incentive to make it good rather than “good enough to ship."

This title shows the process of cleaning code. Rather than just illustrating the end result, or just the starting and ending state, the author shows how several dozen seemingly small code changes can positively impact the performance and maintainability of an application code base.

How often do you hear people say things like this? "Our JavaScript is a mess, but we’re thinking about using [framework of the month]." Like it or not, JavaScript is not going away. No matter what framework or ”compiles-to-js” language or library you use, bugs and performance concerns will always be an issue if the underlying quality of your JavaScript is poor. Rewrites, including porting to the framework of the month, are terribly expensive and unpredictable. The bugs won’t magically go away, and can happily reproduce themselves in a new context. To complicate things further, features will get dropped, at least temporarily. The other popular method of fixing your JS is playing “JavaScript Jenga,” where each developer slowly and carefully takes their best guess at how the out-of-control system can be altered to allow for new features, hoping that this doesn’t bring the whole stack of blocks down. This book provides clear guidance on how best to avoid these pathological approaches to writing JavaScript: Recognize you have a problem with your JavaScript quality. Forgive the code you have now, and the developers who made it. Learn repeatable, memorable, and time-saving refactoring techniques. Apply these techniques as you work, fixing things along the way. Internalize these techniques, and avoid writing as much problematic code to begin with. Bad code doesn’t have to stay that way. And making it better doesn’t have to be intimidating or unreasonably expensive.

Cites successful examples of community-based policing.

Jack the Ripper and legacy codebases have more in common than you'd think. Inspired by forensic psychology methods, you'll learn strategies to predict the future of your codebase, assess refactoring direction, and understand how your team influences the design. With its unique blend of forensic psychology and code analysis, this book arms you with the strategies you need, no matter what programming language you use. Software is a living entity that's constantly changing. To understand software systems, we need to know where they came from and how they evolved. By mining commit data and analyzing the history of your code, you can start fixes ahead of time to eliminate broken designs, maintenance issues, and team productivity bottlenecks. In this book, you'll learn forensic psychology techniques to successfully maintain your software. You'll create a geographic profile from your commit data to find hotspots, and apply temporal coupling concepts to uncover hidden relationships between unrelated areas in your code. You'll also measure the effectiveness of your code improvements. You'll learn how to apply these techniques on projects both large and small. For small projects, you'll get new insights into your design and how well the code fits your ideas. For large projects, you'll identify the good and the fragile parts. Large-scale development is also a social activity, and the team's dynamics influence code quality. That's why this book shows you how to uncover social biases when analyzing the evolution of your system. You'll use commit messages as eyewitness accounts to what is really happening in your code. Finally, you'll put it all together by tracking organizational problems in the code and finding out how to fix them. Come join the hunt for better code! What You Need: You need Java 6 and Python 2.7 to run the accompanying analysis tools. You also need Git to follow along with the examples.