Dr. Java on Becoming a Solid Developer

Discussions

Blogs: Dr. Java on Becoming a Solid Developer

  1. Dr. Java on Becoming a Solid Developer (20 messages)

    In his blog, Dr. Java gives six solid tips on how to become a solid developer. He starts the post by defining what it means to be a solid developer. From here he lays out 6 principles that should be followed.

    These principles are;

    1. Make sure your class represents a single thing
    2. Early on think about the interaction between classes and their not implementation
    3. Write methods that are focused on a single task
    4. Keep your methods no larger than 10 lines of executable code
    5. Watch your use of exceptions
    6. Don't try to be fancy, get the job done

    The blog has a brief description of each of these principles.

    Threaded Messages (20)

  2. Keep your methods no larger than 10 lines of executable code

    I think this is a bit extreme, and can lead to a lack of readability. I would rather have a few dozen lines of clearly commented code where things are explicit than having to follow a series of deeply nested method calls. Very short method calls are more appropriate in languages like Pascal where procedures and functions can be cleanly nested, so that their use and scope is clear.
  3. I think this is a bit extreme, and can lead to a lack of readability.

    I will respectfully disagree. This is a rule that I follow and I've had more then one comment on how understandable my code is.

    - Kirk
  4. I think this is a bit extreme, and can lead to a lack of readability.
    I will respectfully disagree. This is a rule that I follow and I've had more then one comment on how understandable my code is.- Kirk

    The thing with Pascal is that you can nicely bundle related functionality by nesting things - it can make things very clear. I find the lack of this in C-style languages to be ugly; I often feel that I need at least another way to categorise code of than just package/class/method. I would feel a lot more comfortable about dividing up my methods more if this were available.

    I am not suggesting huge methods by any standards, but 10 seems small; if you have a conditional or switch with more than a couple of sections, where is the room for anything else?
  5. method length[ Go to top ]

    I am not suggesting huge methods by any standards, but 10 seems small; if you have a conditional or switch with more than a couple of sections, where is the room for anything else?

    i cant speak for the author but i assume he means 10 lines of code excluding things like lines that only have brackets on, or lines that only have operators on etc... that seems more reasonable.
  6. re: method length[ Go to top ]

    I'm a big fan of keeping methods short. However I usually arrive at short, "tight" methods after applying a liberal dose of ComposeMethod or ExtractMethod refactorings. The first cut is always a bit messy! ;)

    10 lines? I usually can be quoted as saying 20... but whatever. As long as it's clean and easy to read, which I think is more to the point then the exact line number. It's safe to say the 200 lines in a method is probabably too long. :)

    -j
  7. You can't possibly believe that this is the golden rule. Look at your average persistence method. How many times have we all done this? Are we all "Flaccid Java Developers" or just the ones who don't use code generation to arrive at the same place?

    try
    ResultSet rs = null;
    PreparedStatement ps = null;
    Collection keys = new ArrayList();

    StringBuffer sql = new StringBuffer();
    sql.append("");
    ...


    ps.setLong();
    ps.setString();
    ps.setString();
    ...

    ps.execute();

    loop of your choice to populate keys
         add object
    catch
    ...
    finally
    ...
    return
  8. No need to get aggrevated folks. Everyone who categorically posts something like that ("use 10 lines", or 15, or 500, etc.) for all to see, automatically sets himself/herself up for criticism. You all are missing the point. It's not about the number of lines (although I find that 10-15 usually works just fine - in most cases.) The point is: make your methods instantly readable! In most cases, a method should contain just enough "bullet points" for anyone to see the high-level picture. Just like the index in a book. For each such high-level bullet point, one should be easily drill down and see more detail - if they have to. And, yes, if your methods consistently have 100-200 and more lines, you suck, and there's nothing you can say in your defense! :))

    Your example, Kyle, is arguable. ;) I have done things like that differently. For example, you can come up with a generic [framework] method on a base class that implements the reused JDBC stuff plus all catches and finally stuff. (Or, better yet, implement a safety net properly, use RT exceptions and dont't worry about them untill they reach the safety net where they are all handled, use an aspect for your "finally"s, etc., if they are all the same... but I'm getting carried away... :-) ) Inside is a call to the abstract callback method that subclasses implement to populate custom objects from the result set... If I see that I keep doing the same thing "many times", I tend to isolate it and reuse it instead of copying. You probably do the same... right? :) Of course, if your population method has to deal with tons of fields, then you have no choice but list them all and end up with many lines like "x = rs.getString(...);"

    Also, I wouldn't jump at the guy for his poor English [many of us here boast the same writing skills] and lack of detail in that blog. It was written in a hurry - obviously, and for the same reason most people write blogs. Too many people these days decide that they have something very important to say to the world, so they all become bloggers now...

    All that aside, the points listed in the article are all valid points, and I don't really see why people get fired up about that. The only lame statement, I agree, is #5. It really carries no meaning unless you seriously elaborate on the subject. But we've already had enough discussions on TSS about exceptions. The good sign is that even Sun is silently admitting their sins by dropping checked exceptions in EJB3. ;)
  9. For me, the example is a bit contrived, but not because it didn't implement a framework to "expose JDBC", which is an already small and easy to use API. It's contrived because the moment you start thinking about implementing a framework for the JDBC API, you also had better be considering O/RM. In fact, I havent used JDBC in about a year. I looked up an example in some generated code for that post.

    I have seen only one example of something like this framework you mention and IT also was developed by someone by the name of "Constantine V". It was hilarious. It had this base class that had a ResultSet data member. Every subclass which called up to it would reset that ResultSet. It was basically an unecessary abstraction. When all was said and done, it actually obfuscated and even hid some features of JDBC.

    Where the "10 line rule" is becomes even more problematic is if you are using the DOM API with a large Document. I have seen many and have coded a few hideous monsters using DOM. XPath.......Ahhhhhhhhhhhhh, relief.
  10. I agree, I think specifying a number of lines for each method is crazy, as far as I can see, a method should be no bigger than it needs to be, some could be 5, others 50.
  11. What about unit tests?[ Go to top ]

    Perhaps real (solid) developers don't need to write JUnit tests. ;-)
  12. Good points but...[ Go to top ]

    The author makes good points but
    1. The first two are really design guidelines [subject to interpretation of the word developer] I don't see how they make one become a solid developer
    2. It takes a lot more than the 6 tips to become a solid developer (contrary to the first line in the author's blog)

    C
    http://chintanrajyaguru.com/blog
  13. This is pathetic[ Go to top ]

    Regarding content, these principles are misguided and inadequate. For those that are correct in an abstract sense, the article does not guide on how to achieve or even measure them.

    For example, "Watch your use of Exceptions" is fine until the author admits that he "can't express how exceptions are misused". This article contains no wisdom.

    Worse, the author's style is vulgar and his grasp of grammer is poor. The author's obsession with sexual inuendo discusts me.

    This reflects poorly on the state of TSS. At the same level of the eyecatching glossy magazine that promises six ways lose weight or 25 ways to spice up your marriage, this article promises but does not deliver. It cannot even spark a useful and illuminating debate. Do the responders ask "If exception use is abuse, then why do we have them?". No. They debate whether 7 or 25 LOC are the better number.

    Avoid this fluff.
  14. This is pathetic[ Go to top ]

    Regarding content, these principles are misguided and inadequate. For those that are correct in an abstract sense, the article does not guide on how to achieve or even measure them.For example, "Watch your use of Exceptions" is fine until the author admits that he "can't express how exceptions are misused". This article contains no wisdom.Worse, the author's style is vulgar and his grasp of grammer is poor. The author's obsession with sexual inuendo discusts me.This reflects poorly on the state of TSS. At the same level of the eyecatching glossy magazine that promises six ways lose weight or 25 ways to spice up your marriage, this article promises but does not deliver. It cannot even spark a useful and illuminating debate. Do the responders ask "If exception use is abuse, then why do we have them?". No. They debate whether 7 or 25 LOC are the better number. Avoid this fluff.

    I was reacting to the post here. Your criticisms of the original blog entry are fair, but style and innuendo don't detract from the principles summarised here. I see little to disagree with in the TSS summary of the blog - it states the very obvious, except, in my view, the '10 lines' principle. It seems to be picking an arbitrary small number and making it a rule. Anyway, this principle seems to me to be partly redundant because of No. 3.
  15. Dr. Java is pathetic[ Go to top ]

    I agree wholeheartedly with Neil Pitman's comments. We in the developer community don't need a vulgar, two-bit, self-absorbed hack whose grasp on English grammar is so tenuous it makes his (or her) writing, if not completely unintelligible, certainly distracting to read.
    The first mistake this writer makes is to claim the pen name of "Dr. Java", neither part of which is justified by this blog entry.
    With the exception of (including but not limited to ;) the ridiculously dogmatic "10 lines" statemet and the blogger's embarrassingly flagrant lack of knowledge about exceptions, I will admit that there are kernels of truth present. Unfortunately for the "Dr.", these are truths that have been around for at least ten to fifteen years and repeated (to good effect) by many writers since. This blog writer, unfortunately, hardly appears to understand them himself. So I have to say that I also thought higher of TSS until now. For whatever it's worth, TSS, please remove this blogger from your list of resources.
    Another problem with this blogger's diatribe is the use of the limp term "Solid" in the title. Being non-quantifiable in this context, this term shows that the "Dr." has no clear objective for this blog entry, and in "aiming low" with the "advice" given, is not concerned with what the reader might take away after investing his time. I for one do not like to waste time on something that cannot hope to make me anything more than a "just adequate" developer.
    Although, it is certainly not extremely difficult, in my opinion there is no shortcut to becoming an experienced/knowledgable/useful/better... (whatever your current goal) developer. So, to conclude (and they all rejoiced. Yayyy.) in the spirit of offering more than just negativity, here's some advice for making yourself a better developer and person that I have come across many times from worthy sources and which I believe and live:
    - Read. Everything you can, including stuff about your craft. Beware of dogma. Don't drink the "kool-ade". Educate yourself. (How else will you know what's dogma and whose serving "kool-ade"?)
    - Develop. This is where it all comes together. You become experienced by having experiences.
  16. for programming languages like Java, we have IDE tools like Rational Application Developer which help us do code review and refactoring. I would recommend the developer to be skilled in using these IDE tools and of course basics of programming language like Java.

    There is a lot more other than those 6 lines to become a strong developer.
  17. I'm not normally a real sticker for grammatical errors, but this article is horrible. From the very first sentence the errors distract the reader from the point.

    Sorry. I. Just. Can't. Read. It.
  18. I have to agree. This person certainly is not a solid writer. So many errors and typos. Too bad spellcheckers (if one was even used) can't be as powerful at detecting such mistakes as compilers are for syntax errors.
  19. It would be nice if you people would good judgment when interpreting these rules. By no means are they hard fast rules, especially the 10 lines of executable code. Before this forum gets out of hand, let me clarify something real fast. It does read "10 lines of EXECUTABLE CODE" How should you interpret this? Easy. Ask yourself this one question: Are curly brackets, comments, white space (new lines, tabs, spaces, etc.), and anything that doesn't get execute considered executable code? This is just the lexical grammar. The reason why I posted this rule … Drum roll please … to get people to think in terms of "Logical units of work". Just for my chits and giggles: Common Sense: "God, this method is huge! It must be around 100 lines of code" Moron: "No, it's only 50 lines of executable code." Common Sense: "Do you think this method is trying to accomplish too many things at one time?" Moron: "Who cares? It does the primary function right?" Common Sense: "Yes, but for many reasons, this can be logically broken down." Moron: "Nonsense! You're just a moron with poor grammar! I can't read your Blog. You suck! You're vulgar, Rude, insecure, and well, lame!" Common Sense: "OK, please leave while I refactor your code into something more logical." Moron: "YOU SUCK YOU SUCK YOU SUCK!" I really don't care if you follow my rules or not. I don't care if you write your entire application as one huge method. All I care about is that your common sense doesn't die off and your co-workers take you outside to bash your brains out. We need morons! Dr. Java Tips for Tricks
  20. Bravo![ Go to top ]

    Bravo, Dr. Java. I read your blog - and contrary to other people's comments about style/grammar/language, I agree with you. I am far from a solid developer but I do know this - everytime I have seen a piece of code where I have marveled at the author, it has followed almost all your principles. To the detractors out there, I will say this. Guys, wisdom is wisdom, irrespective of the language used. He is not being abusive. I find it interesting how most of you take his Point #4 so literally. He is not asking you to "write 10 lines, no more, or I'll shoot!!". He is merely saying that if you need to write copious lines of code into a single method, you're doing something wrong. Dr. Java - thank you for restoring my faith. I read about your points on classes, methods (work towards what they do, not just the how!!!) and the way they can get out of hand - bravo! Someone once said to me - in software, if you're thinking TOO hard, you're doing something wrong. Thank you for breaking that up into actual components in this article. Simple as your points seem (and obvious) - I cannot count the number of times I have forgotten them. These go up on my screen-of-fame!
  21. Dr. Java's "colorful" response to all the discussion proves many of the points that have been stated here about him, and once again it seems clear that this person is, at best, unprofessional and certainly unworthy of being a spokesman for or to any serious development community. I find it amazing that the "Dr." attacked those who engaged in a mostly serious discussion, however laborious in its fixation on minute and esoteric details, of a topic (i.e., method length) instigated by the "Dr." himself. He prefered to rant and rave about how stupid they are for thinking that when he wrote "10" he really did mean "10". This person apparently can't clarify himself and wants to blame everyone else for his own inability to express a complete and clear thought in the English language. Dr. Java, you wrote a poorly stated and poorly defended point. You should feel some measure of shame, and you would do well to acquire humility and education before putting yourself up on a pedestal. True leaders are "giants" in their own right and don't need a pedestal or self-agrandizement. The only reason I have read this "Dr. Java", and been motivated to comment, is because I was attracted by the headline in an issue of The ServerSide newsletter. I am deeply disappointed in TSS for highlighting this writer, and I can only hope their editors will be more selective in choosing writers to represent "their voice." I am absolutely more skeptical about TSS and taking the time to read any links.