• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What can make code unintentionally difficult to debug ?

 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Marshal
Posts: 79179
377
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The chap who runs MindProd has some suggestions.

This discussion belongs elsewhere
 
Campbell Ritchie
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

A few minutes ago, I wrote: . . .
This discussion belongs elsewhere

And where better than MD!
 
Campbell Ritchie
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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()

 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 1810
28
jQuery Netbeans IDE Eclipse IDE Firefox Browser MySQL Database Chrome Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 543
4
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 1810
28
jQuery Netbeans IDE Eclipse IDE Firefox Browser MySQL Database Chrome Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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."
 
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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..."
 
Bartender
Posts: 9626
16
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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



IOC / Dependency inversion / injection
 
reply
    Bookmark Topic Watch Topic
  • New Topic