I've heard it takes forever to grow a woman from the ground
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Co-Author of <a href="http://www.oreilly.com/catalog/jswing2" target="_blank" rel="nofollow">Java Swing</a><br />Co-Creator of <a href="http://www.sun.com/training/catalog/courses/CX-310-055.xml" target="_blank" rel="nofollow">SCJP 5.0</a> and <a href="http://www.sun.com/training/certification/java/associate_beta.xml" target="_blank" rel="nofollow">SCJA</a> exams
Co-Author of <a href="http://www.oreilly.com/catalog/jswing2" target="_blank" rel="nofollow">Java Swing</a><br />Co-Creator of <a href="http://www.sun.com/training/catalog/courses/CX-310-055.xml" target="_blank" rel="nofollow">SCJP 5.0</a> and <a href="http://www.sun.com/training/certification/java/associate_beta.xml" target="_blank" rel="nofollow">SCJA</a> exams
Originally posted by Warren Dew:
Once I know that we're talking about server/icon pairs, the rest of the code becomes far less cryptic. I think this is an excellent example of why beginning coders should put in some comments - it's easier to learn to put in a few comments than to learn good refactoring.
To me, the main advantage of the third example is that it eliminates a lot of unnecessary whitespace. I don't think it actually has fewer code lines than the original. It is better organized, but the truth is that even the original is far better than typical code I see (e.g., it has no functions longer than 100 lines).
Beyond the third example, you're taking advantage of things that weren't available to the original coder, so I don't think it's a fair comparison - though I agree it's an illustration of what can be further improved. And in real code, you couldn't just leave out a trim() that was there before, as that would introduce a bug.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Originally posted by Joseph George:
I feel like commenting comes in to play when you're on a project with a battallion of programmers. What kind of commenting does the little guy, workin' by himself, do for commenting?
Originally posted by Jeff Walker:
you should document all pre- and post conditions before a block of code, loop invariants for all loops, complex 'if' statements that have multiple lines of boolean logic, and all classes and methods. Variables should be documented with a one line description next to them when their meaning is not easily discernable from the name used.
I've heard it takes forever to grow a woman from the ground
I've heard it takes forever to grow a woman from the ground
Originally posted by Jeff Langr:
The tag "author" doesn't mean I don't program in the "REAL WORLD," by the way.
Co-Author of <a href="http://www.oreilly.com/catalog/jswing2" target="_blank" rel="nofollow">Java Swing</a><br />Co-Creator of <a href="http://www.sun.com/training/catalog/courses/CX-310-055.xml" target="_blank" rel="nofollow">SCJP 5.0</a> and <a href="http://www.sun.com/training/certification/java/associate_beta.xml" target="_blank" rel="nofollow">SCJA</a> exams
Originally posted by Warren Dew:
Question regarding JavaDoc:
Last time I was on a project which parsed JavaDoc (admittedly four years ago), examples like the ones given upthread would result in scattered asterisks throughout the JavaDoc, because the line breaks would be autogenerated rather than following the original format. Generating pretty JavaDoc required cluttering up the comments with HTML tags for paragraph breaks and such.
Has that been fixed?
Co-Author of <a href="http://www.oreilly.com/catalog/jswing2" target="_blank" rel="nofollow">Java Swing</a><br />Co-Creator of <a href="http://www.sun.com/training/catalog/courses/CX-310-055.xml" target="_blank" rel="nofollow">SCJP 5.0</a> and <a href="http://www.sun.com/training/certification/java/associate_beta.xml" target="_blank" rel="nofollow">SCJA</a> exams
Originally posted by Dave Wood:
Jeff, please don't think I was directing that at you! I was going back to the original post which was from someone in high school asking about commenting code. My reference to the REAL WORLD was just meant to differentiate between writing code for yourself and writing code in a business setting.
-dave (another author who also works in the RW, FWIW)
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Originally posted by Warren Dew:
However, I also think it's dangerous to say things that might come across to a beginner as, "making the code have fewer lines is more important than putting in error checking code" - I know you didn't say or mean that, but a newbie could come away with that impression.
For those of us who feel that all duplicate code should be refactored, I think it's a bit of a trap to talk about the resultant reduction in size of the code. Duplicate code should be refactored even if the result has a few more lines than the original - which I've found that it often does, at least initially, because the addition of two function calls and the function declaration, along with sometimes a new class, can be more than the number of lines removed to the function. The advantage of refactoring the duplicate code is not so much the reduction in the size of the code base, as in the centralization of the code - the fact that if the code has to be changed, or if a bug has to be fixed, the changes and fixes need only be done once rather than twice. If you or I think about that, it's obvious - but it may not be obvious to the newbie who is trying to figure out why people think refactoring is good.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
I agree that beginner should put in a few more comments.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Jeff Walker:
But this following example does need its comment, don't you think?
// Split it on ";"
infoVector = x(onePair, ";");
One final example,
...
int a = 14;
if (((a ^ b < 2) || (b >= c/2)) && (c!= d))
...
may very well need some explaining, since the variable names are poorly chosen, and the boolean result is certainly not clear. Especially the nested parentheses and the boolean operators make it hard to read.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Jeff Langr:
This is randomly plucked from a class in my current client's system; it's not a class I'm intimately familiar with:
This Javadoc comment adds no value whatsoever. It only serves to clutter the code and waste my time stating something the method signature clearly states. In the shops where developers are required to write a javadoc comment for each method, this is what most of them look like. Excessive documentation wastes time.
Sure, IDEs generate most of this piffle easily.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Peter den Haan:
Can I recommend McConnell's Code Complete? Don't be distracted by the fact that it doesn't use Java or any other object-oriented language:
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Forget this weirdo. You guys wanna see something really neat? I just have to take off my shoe .... (hint: it's a tiny ad)
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|