Book still relevant? "Essential Java Style"

T

tom fredriksen

Hi

I recently came across a book written by Jeff Langr called "Essential
Java Style" which was published in 2000.

What I am wondering is, if anybody who has read the book would say that
the contents of the book is still relevant with jdk 1.5.

I am no expert on java, therefor I am a bit uncertain of whether the
information and techniques explained are outdated or not.

Any thoughts?

regards

tom
 
C

Chris Smith

tom fredriksen said:
I recently came across a book written by Jeff Langr called "Essential
Java Style" which was published in 2000.

What I am wondering is, if anybody who has read the book would say that
the contents of the book is still relevant with jdk 1.5.

I would say that there are better books out there if you're interested
in learning how to write better Java code. Look at Josh Bloch's famous
Effective Java, and Martin Fowler's Refactoring, for example. Jeff's
book spends a LOT of space on really basic stuff, like what modifiers to
use when declaring a constant, that you may find to be a waste of paper.

Nevertheless, not much from 1.5 specifically causes the book to be much
more outdated than it ever was. You will, of course, see pre-1.5 raw
collection types and such; but that's pretty unavoidable in the midst of
this transition period. There's also a bit of strong excitement about
the Collections API that will seem somewhat odd to a modern Java
programmer. (The book was written when the Collections API was a New
Thing.)

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
R

Roedy Green

I am no expert on java, therefor I am a bit uncertain of whether the
information and techniques explained are outdated or not.

On of the classic such books is Steve McConnell's Code Complete
written primarily about C. It is not that this material goes stale,
but that you may require the time-honoured principles also applied to
the latest syntax specifically. It may even be easier to grasp the
essentially without all the clutter of the latest syntax.
 
J

jjlangr

Greetings Chris and Tom,

Chris said:
I would say that there are better books out there if you're interested
in learning how to write better Java code. Look at Josh Bloch's famous
Effective Java, and Martin Fowler's Refactoring, for example. Jeff's
book spends a LOT of space on really basic stuff, like what modifiers to
use when declaring a constant, that you may find to be a waste of paper.

It's also six years old, and since then, there are a lot of lessons
I've learned. Indeed, it's a pretty basic book. I would, however,
characterize the above criticism of the book as somewhat inaccurate.
It's really about the organization and expressiveness of code, and not
about syntactical details. And as basic as its concepts are, my
experience from looking at lots and lots of poorly structured,
difficult-to-maintain code since then shows that most Java programmers
(at least 80%) don't "get it," six years later.

As far Effective Java is concerned, it's a great book, and one I
heartily recommend. Unfortunately, it too is considerably out of date.
And as much as I like it, I'd rather Bloch had done more separating the
"defensive coding" discussions from the maintainable coding
discussions.

Refactoring is also an essential book, but its primary goal is not as a
book on how to write better code--it's more about the steps you need to
take to get there.

Mr Green mentioned Code Complete, which I contributed some feedback to.
It too is a great book, but it's pretty overwhelming and tries to be
everything to everybody, OO, procedural, Java, C++, etc.
Nevertheless, not much from 1.5 specifically causes the book to be much
more outdated than it ever was. You will, of course, see pre-1.5 raw
collection types and such; but that's pretty unavoidable in the midst of
this transition period. There's also a bit of strong excitement about
the Collections API that will seem somewhat odd to a modern Java
programmer. (The book was written when the Collections API was a New
Thing.)

This is a good point. The book was written in early 1999 and actually
came out in Fall 99 (but it's copyrighted 2000). Naturally it would
have nothing to do with J2SE 5.0. I have no idea what you mean by
"transition period," by the way, since we're talking about Java six
years ago. As far as the collections API, it was a new thing at the
time. Yet once again, it's six years later, and I still see plenty of
programmers still using Hashtable and Vector, and inappropriately at
that.

I've distilled most of the lessons from Java Style into three style
patterns; I wrote about this a few years ago in Software Development.
You'd be better off reading the article than buying the book, although
the book is now probably only $5 at Amazon, and SD now charges for some
of its article access. Tell you what, Tom: if you want a copy of the
book, send me an address and I'll ship you one free (unless you're out
of the US, in which case I'll send it to you for the cost of postage).

You might also take a look at Agile Java for information about J2SE
5.0.

Jeff L.
 
C

Chris Smith

And as basic as its concepts are, my
experience from looking at lots and lots of poorly structured,
difficult-to-maintain code since then shows that most Java programmers
(at least 80%) don't "get it," six years later.

I wonder how much of this depends on the environments where one tends to
look at code. I doubt there's anyone here who doesn't see a biased
sample for a variety of reasons. Consultants only see the code of
people who hire consultants. Open source enthusiasts see code that is
developed without the benefit of an institutional culture or mutual
review process. Average developers tend to mainly see code developed
inside their organizations. All of this can lead to a profound bias in
perceptions of what "most" Java programmers do.

I don't know your background, Jeff, but it would be interesting use of
an omniscient moment to observe how much effect these biases have.
As far Effective Java is concerned, it's a great book, and one I
heartily recommend. Unfortunately, it too is considerably out of date.

There are a few recommendations that are obsoleted by Java 1.5 features
(largely because Josh had such a large role in deciding what to change
in 1.5, and he naturally chose exactly those areas where he felt that
Java programmers tend to trip themselves up). Nevertheless, I tend to
see Effective Java as very relevant in 95% of what it says. The
remaining 5% is pretty obvious (type-safe enum pattern, for instance).
And as much as I like it, I'd rather Bloch had done more separating the
"defensive coding" discussions from the maintainable coding
discussions.

Since a major point of the book is that they are congruent in most
cases, I suppose that separating the two would actually have meant
changing part of the book's message.
Refactoring is also an essential book, but its primary goal is not as a
book on how to write better code--it's more about the steps you need to
take to get there.

Yes, that is the perspective from which the book is written. I find the
content far more useful, though, when read from a different angle.
There is a lot of really good information in there on:

a) The low-level design alternatives that can be chosen when writing
code. This is often eye-opening to novice programmers who have never
even seen one alternative used over the other.

b) Interspersed in the step-by-step instructions, a nice collection of
all the ways that each design decision affects the surrounding code.
Seeing a complete list of these effects helps train the mind to make
informed decisions about design.

I find this far more useful than the nominal purpose of the book. When
I'm asked how to learn good programming idioms and low-level design
decisions, one answer that's near the top of my list is to go through
this book and try out these refactorings on real-life code to get a feel
for their effects.

The stylistic and low-level design benefits of the book are belied by
the opposing natures often found in the text. That is, often the
refactorings are about how to change from A to B, and then from B back
to A. By looking at the effects of each refactoring in the pair and the
"motivation" sections of each, it's possible to extract a pretty good
description of when to make one decision versus the other.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
J

Jeff Langr

Chris said:
I wonder how much of this depends on the environments where one tends to
look at code. I doubt there's anyone here who doesn't see a biased
sample for a variety of reasons. Consultants only see the code of
people who hire consultants. Open source enthusiasts see code that is
developed without the benefit of an institutional culture or mutual
review process. Average developers tend to mainly see code developed
inside their organizations. All of this can lead to a profound bias in
perceptions of what "most" Java programmers do.

I don't know your background, Jeff, but it would be interesting use of
an omniscient moment to observe how much effect these biases have.

I've seen a larger variety and amount of code than you might guess. I've
been both employee and consultant in the past 8-9 years of doing Java,
and again both in the 15+ other years of doing other development things.
I certainly don't claim to be omniscient, but I don't think I have a
high level of bias, either. Most code is less than stellar.

I'd be happy if programmers read any of the books we've mentioned, such
as Effective Java or Code Complete, whether or not we agree on their
messages. Most don't, unfortunately.

-Jeff L.
 
M

Monique Y. Mudama

I've seen a larger variety and amount of code than you might guess.
I've been both employee and consultant in the past 8-9 years of
doing Java, and again both in the 15+ other years of doing other
development things. I certainly don't claim to be omniscient, but I
don't think I have a high level of bias, either. Most code is less
than stellar.

I'd be happy if programmers read any of the books we've mentioned,
such as Effective Java or Code Complete, whether or not we agree on
their messages. Most don't, unfortunately.

Speaking as a person who's read lots of books but sometimes writes
some "less than stellar code": believe me, I know when my code is
ugly, and I do my best to design it so that it doesn't start that way,
and to refactor it whenever I see an opportunity. I'm really proud of
some things I've designed and coded. Others ... not so much. I know
that I've "done good" when I look at my OO code and think, wow, it's
so simple.

You know the reasons that these things happen as well as I do. With
infinite time, etc, etc, blah blah blah. I do think that having
working, ugly code is better than having no code at all because you
couldn't think of an elegant way to do it. That is, it's better if
you're trying to get something out the door.
 
C

Chris Smith

Jeff Langr said:
I've seen a larger variety and amount of code than you might guess. I've
been both employee and consultant in the past 8-9 years of doing Java,
and again both in the 15+ other years of doing other development things.
I certainly don't claim to be omniscient, but I don't think I have a
high level of bias, either. Most code is less than stellar.

I'm afraid you interpreted my comment as "no you're wrong!", when that's
not what I meant. Certainly most code could be a lot better. I have my
complaints about the code that I see and work with on a regular basis.
I just see different things. For example, I can't recall the last time
I saw code that made use of Hashtable or Vector, except in one case
where the code was specifically designed to run under Java 1.1.
I'd be happy if programmers read any of the books we've mentioned, such
as Effective Java or Code Complete, whether or not we agree on their
messages. Most don't, unfortunately.

Indeed. Unfortunately, the problem is self-compounding. Programmers
who read such books already understand that such concerns are valid; if
they didn't understand it, they wouldn't have bought the book. The
books are great, but they are doomed by circumstance to preach to the
choir, to some extent. That's not to say that the choir couldn't use a
little preaching, now and then...

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
J

Jeff Langr

Chris said:
Indeed. Unfortunately, the problem is self-compounding. Programmers
who read such books already understand that such concerns are valid; if
they didn't understand it, they wouldn't have bought the book. The
books are great, but they are doomed by circumstance to preach to the
choir, to some extent. That's not to say that the choir couldn't use a
little preaching, now and then...

Good points.

-Jeff
 
J

Jeff Langr

Monique said:
Speaking as a person who's read lots of books but sometimes writes
some "less than stellar code": believe me, I know when my code is
ugly, and I do my best to design it so that it doesn't start that way,
and to refactor it whenever I see an opportunity. I'm really proud of
some things I've designed and coded. Others ... not so much. I know
that I've "done good" when I look at my OO code and think, wow, it's
so simple.

You know the reasons that these things happen as well as I do. With
infinite time, etc, etc, blah blah blah. I do think that having
working, ugly code is better than having no code at all because you
couldn't think of an elegant way to do it. That is, it's better if
you're trying to get something out the door.

I still write plenty of ugly code and try to clean it up before moving
on. It's extremely difficult to keep poor code from creeping into any
system, as you suggest. And you're correct, better to have working
product than nothing at all. But it is where the troubles all begin;
poor code begets worse code and more costly maintenance down the road.

-Jeff
 
M

Monique Y. Mudama

I still write plenty of ugly code and try to clean it up before
moving on. It's extremely difficult to keep poor code from creeping
into any system, as you suggest. And you're correct, better to have
working product than nothing at all. But it is where the troubles
all begin; poor code begets worse code and more costly maintenance
down the road.

Okay, cool. I get defensive, I guess, when people say that a good
programmer/developer/engineer/architect will *always* produce
beautiful code. Maybe people don't say that, but I guess I always
assume it's implied when some expert talks about best practices.

I agree 100% that ugly code is evil and a maintenance nightmare.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top