Karl Beecher

Thank you to everyone who engaged with questions and feedback.

Congratulations to the winners, I hope you enjoy the book and find much valuable advice therein.

And thank you to everyone at Coderanch responsible for organising this promotion. I enjoyed very much taking part. I've found that I like it here and will endeavour to stick around and stick my nose into things.

If anyone has any more questions or messages for me, do feel free to reach out, either here or on Twitter (@karlbeecher).

Take care!

Campbell,

There's been quite a bit of research into this (my book includes some references). It's hard to summarize because the results are mixed and occasionally counter-intuitive, but broadly speaking the research suggests:

* Smaller subroutines are cheaper to fix
* The number of bugs in a routine tends to increase with size (although defect density doesn't increase with size!)
* Routines with a higher McCabe complexity (basically, the number of possible different paths through a routine) are harder to understand and more prone to error. The recommended limit hovers around 10-15. This is not necessarily to do with routine size (short routine can be complex) but longer routines tend to have a higher complexity.

Not a straightforward question to answer, but I hope that's helps!

Hi Michael,

Good question! I do mention version control in a section concerning tools (you should be able to see it in the free sample available at Amazon), but only briefly.

I would love to have discussed it, it's important and a potential source of some great laughs (as @Junilu ably demonstrated!). However because of space restrictions, I focused only on the writing of code. The wider 'software engineering' stuff I consciously left out.

I'd love to do a companion book--or maybe an expanded section edition--that discusses how (not) to do software engineering. VC would fit right in. If there's good feedback from this book, maybe I can make it happen!

I don't think Bloch and I give any opposing advice on inheritance. If memory serves, my book discusses the problems with deep inheritance hierarchies, whereas Bloch's doesn't. (This comes only from memory however, so don't take my word as gospel. I don't want to unwittingly do a disservice to Bloch's book.) Similarly, Bloch's book contains some advice that mine doesn't.

Hi Meenakshi,

Your "junior folks" are just people I'm aiming at. As beginners, we write code and go through a period of working out what are good practices and what kinds of practices cause headaches. This can take time (hence the old phrase about getting the first bad 10,000 lines of code out of your system).

By reading this book, beginners can learn some of the most common bad practices to avoid without having to make those mistakes themselves. By learning practices to avoid, this helps them get more productive within a quicker span of time.

Also, they'll learn the reasoning behind the good practices, so they come to appreciate why they ought to follow them (instead of following them 'just because').

Hi Campbell,

I assume this question is for me

Inheritance gets its own section in the book. I don't label it as something inherently good or bad. It is a useful technique but one that can be easily abused in ways that cause headaches. I chose the most migraine-inducing misuses and discussed why they ought to be avoided.

Hi Will,

The book discusses general programming practices, it just happens to use Java as a demonstration language. Most of the material generalises to other languages.

It mentions a few functional programming approaches as suggested improvements over imperative approaches, but to say that it 'covers' functional would be too grand a word.

Hi Paul,

Prerequisite 1: Understand the basic concepts of unit and integration testing.

It's important to understand what software testing tries to achieve, and how unit and integration testing help toward that. Read about testing in theory (i.e. independent of any particular language) and understand things like black box vs white box, equivalence partitioning, validation vs verification, and the contrast between proving a program correct and empirically testing it. Any good software engineering book will discuss these.

Prerequisite 2: Be able to write basic test cases using frameworks like JUnit.

This is actually quite straightforward. If you can write some code, write a test class that tests at least one method, and run the test class so that it executes correctly, you meet this prerequisite. Most IDEs make this very simple by building JUnit into the IDE. Try it out in your favourite IDE.

Is fewer lines of code always better?

I really like Junilu's answer to this and am tempted to say no more on the matter. The book cites various research on recommended maximum sizes for blocks of code (it varies depending on who you ask), but it's interesting to note there's not nearly as much advice concerning recommended minimum size. That might tell you something about the attitude towards keeping routines as short as necessary but no shorter (to paraphrase Einstein).

Can you list some example of tools here ?

Pages 4-7 of the book discuss tools. You can read them on the free preview on Amazon (https://www.amazon.com/Bad-Programming-Practices-101-Learning/dp/1484234103).

Have you ever heard about Alibaba Java source guideline ? Will it be an advantage to follow this guideline ?

I haven't heard of it. Judging from its GitHub page, it was made public shortly after I begun working on my book. Guidelines are important, but as Junilu says, it's important to understand the reason behind a coding rule (and thus understand what problems it's encouraging you to avoid) before following it.

Hi,

In terms of architecture, the book covers general principles of modular programming and object-oriented programming. You'll learn how to build components which have high cohesion, low coupling, clean and reusable interfaces and you'll learn how to build classes which allow for flexible designs.

Designing good interfaces is a critical element of building large-scale software. Dependency injection is one way--and a fine one, at that--to avoid brittle designs (i.e. designs that tend to break and demand rework when you attempt to change things). Specifically, it is a solution to the problem of a client being responsible for constructing a concrete service object in order to use it. That's not necessarily something a client should do. The server instance should instead be instantiated elsewhere and 'injected' into the client.

Design patterns do not have their own section in the book, but a few examples of them feature throughout.

I hope that answers you questions.

Hi Divya,

The book discusses general programming practices, it just happens to use Java as a demonstration language. Most of the material generalises to other languages.

In a couple of places it touches on version-specific issues -- for example, it talks about functional programming features, which are largely introduced in Java version 8 and not as simple to use as in other languages -- but these instances are rare.

I'd like to echo some of the earlier comments in this thread. Java documentation is notorious for sometimes being quite cryptic, even to experienced hands.

Personally, the best book I've found for introducing Java is Objects First with Java (https://www.bluej.org/objects-first/). I've used this as the coursebook to teach programming novices. I can testify that it will not make you feel stupid... quite the opposite!

Hi everyone,

Thanks for the welcome. Great to be here. I look forward to your questions!