Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What can make code unintentionally difficult to debug ?

 
sid smith
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 49411
62
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The chap who runs MindProd has some suggestions.

This discussion belongs elsewhere
 
Campbell Ritchie
Sheriff
Pie
Posts: 49411
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A few minutes ago, I wrote: . . .
This discussion belongs elsewhere
And where better than MD!
 
Campbell Ritchie
Sheriff
Pie
Posts: 49411
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't let our Moose spit at your code. ← Link
 
sid smith
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 10427
63
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Henry Wong
author
Marshal
Pie
Posts: 21204
81
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
chris webster
Bartender
Posts: 2407
33
Linux Oracle Postgres Database Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
+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.
 
J. Kevin Robbins
Bartender
Pie
Posts: 1794
20
Chrome Firefox Browser jQuery Linux MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Dieter Quickfend
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
J. Kevin Robbins
Bartender
Pie
Posts: 1794
20
Chrome Firefox Browser jQuery Linux MySQL Database Netbeans IDE
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1407
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 64972
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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..."
 
Joe Ess
Bartender
Posts: 9300
10
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sid smith wrote:how (java) code can become difficult to debug,


IOC / Dependency inversion / injection
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic