permaculture playing cards*
The moose likes Meaningless Drivel and the fly likes What can make code unintentionally difficult to debug ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Other » Meaningless Drivel
Bookmark "What can make code unintentionally difficult to debug ?" Watch "What can make code unintentionally difficult to debug ?" New topic
Author

What can make code unintentionally difficult to debug ?

sid smith
Ranch Hand

Joined: May 27, 2014
Posts: 50
In an online forum, I saw one old post in which someone complained that that he/she had the misfortune of having to debug poorly written code. I was curious to know how (java) code can become difficult to debug, given that the developer does not intentionally use anti-debugging tricks and also comments his code well.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39784
    
  28
The chap who runs MindProd has some suggestions.

This discussion belongs elsewhere
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39784
    
  28
A few minutes ago, I wrote: . . .
This discussion belongs elsewhere
And where better than MD!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39784
    
  28
Don't let our Moose spit at your code. ← Link
sid smith
Ranch Hand

Joined: May 27, 2014
Posts: 50
Most of them are just silly jokes and only a few are really good. One more wrench in the works for Java:
Giving the same name to your getter and setter for a variable:

set : Id(7)
get : Id()

Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8186
    
  23

sid smith wrote:In an online forum, I saw one old post in which someone complained that that he/she had the misfortune of having to debug poorly written code. I was curious to know how (java) code can become difficult to debug, given that the developer does not intentionally use anti-debugging tricks and also comments his code well.

Since I assume this was a serious question, about the simplest answer I can give you is: Don't follow all the good advice you've (hopefully) been given about formatting, naming conventions, Object-orientation, modularization and code reuse.

The reason, I suspect, that this has been treated flippantly is that the possibilities are so vast that the only way to deal with it is to laugh about it.

Suffice to say: it's a lot easier to write a bad program than a good one; which is why, in the words of Norvig, it takes about 10 years (or 10,000 hours) to become "good".

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18973
    
  40

Winston Gutkowski wrote:
Since I assume this was a serious question, about the simplest answer I can give you is: Don't follow all the good advice you've (hopefully) been given about formatting, naming conventions, Object-orientation, modularization and code reuse.


Agreed. It is amazing that in today's efforts of formalizing "design patterns", "best practices", and "coding conventions", all done with the best of intentions, that they tend to get abused. I think that one should always keep in mind that there are reasons for those practices -- and if someone finds themselves following them, without knowing the reason why, they stand a great chance of generating bad code (just like anyone else).

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
chris webster
Bartender

Joined: Mar 01, 2009
Posts: 1845
    
  16

+1 for Henry's and Winston's comments above.

My own basic rules are:

(1) Keep It Simple (Stupid). This will help to avoid a lot of pain in the long run (although it's not always easy to make things simple). Complexity is your enemy, and enterprise Java breeds complexity like nothing else I've ever seen.
(2) Assume everything that can go wrong with your code will go wrong, sooner or later.
(3) Remember that nobody else knows how your code works, and you will have forgotten how it works or why you did [clever thing X] by the time you (or some other poor schmuck) have to fix bugs in production.

No more Blub for me, thank you, Vicar.
J. Kevin Robbins
Bartender

Joined: Dec 16, 2010
Posts: 1038
    
  13

sid smith wrote:In an online forum, I saw one old post in which someone complained that that he/she had the misfortune of having to debug poorly written code. I was curious to know how (java) code can become difficult to debug, given that the developer does not intentionally use anti-debugging tricks and also comments his code well.

By using scriptlets. (I can't believe I beat Bear to that one.)

Someone once said "Any idiot can write code that a computer can understand. Good programmers write code that a human can understand."

As much as possible, make your code self-documenting by using variable names that explain what that variable represents (i.e. employeeNumber instead of eNm) and use method names that clearly explain what the method does.


"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 543
    
    4

J. Kevin Robbins wrote:
Someone once said "Any idiot can write code that a computer can understand. Good programmers write code that a human can understand."

Martin Fowler?


Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
J. Kevin Robbins
Bartender

Joined: Dec 16, 2010
Posts: 1038
    
  13

Dieter Quickfend wrote:
J. Kevin Robbins wrote:
Someone once said "Any idiot can write code that a computer can understand. Good programmers write code that a human can understand."

Martin Fowler?

That sounds right.

Although my favorite quote along the same lines is "Write your code as if the next person to maintain it is a homicidal maniac who knows where you live."
Frank Silbermann
Ranch Hand

Joined: Jun 06, 2002
Posts: 1389
sid smith wrote:In an online forum, I saw one old post in which someone complained that that he/she had the misfortune of having to debug poorly written code. I was curious to know how (java) code can become difficult to debug, given that the developer does not intentionally use anti-debugging tricks and also comments his code well.
To debug a program you first have to understand it, and some programs can be very difficult to understand. Aside from purely technical considerations, all the flaws that make English prose difficult to read and understand also make programs difficult to read and understand, as most of the principles of technical writing also apply to programming.

In a text book, every unit has an explicit theme by which the reader would know in which unit a particular issue would be dealt with. Every chapter in a unit would have an explicit theme by which the reader would know where a particular issue would be treated. And so on, down to sections, subsections and paragraphs. The same is true with respect to nested organization of good program code into high-level and low-level classes -- code which doesn't do this is bad code. You would limit method size for comprehensibility just as you would paragraph size and sentence size. When a good writer defines his own terminology, the principles used would be similar to the principles used for coming up with a system of identifiers in the code. A bug is some aspect in which the program does not _quite_ do what you expected it to do. Finding out why and where requires narrowing down possible locations of the bug. Good program organization helps you think this through using ordinary logic.

Aside from program comprehensibility, there are choices that can make a program difficult to debug even if the code is quite understandable. Even if you have it narrowed the problem location to one small module you still need to figure out the precise location and reason the unexpected behavior first occurred. Doing so may require running some tests. If within the same method you mix complex decision logic with hard-coded external interfaces (e.g. databases, message queues, other computers) then it will be very difficult to try out theories; trying to exercise a piece of code to see what it does under various conditions will require orchestrating a whole bunch of other systems in your test -- systems that may unavailable for you to play with. So the same things that make a program difficult to test also make it difficult to debug.
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 543
    
    4

On a higher level: do not accept requests to implement complex behavior that users think they want. Trust me, it's really not what they want.

If nobody has the authority or the guts to say "This is not a good idea. Let's have a meeting about why it isn't and what you're trying to achieve; I'm sure there's a better solution." then any application will end up as a total mess, no matter how good your development team is.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61601
    
  67

Dieter Quickfend wrote:On a higher level: do not accept requests to implement complex behavior that users think they want. Trust me, it's really not what they want.
.

Quoted for truth.

I cannot tell you how many times I've been asked to implemented Rube Goldberg contraptions that were headed off by my asking "Why don't we just do..."


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8964
    
    9

sid smith wrote:how (java) code can become difficult to debug,


IOC / Dependency inversion / injection


[How To Ask Questions On JavaRanch]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What can make code unintentionally difficult to debug ?