Here's a question for those of you who have experience of fixing or enhancing other people's Java code, which I hope will also be really useful for those in the early stages of learning programming. Please contribute!
If you've looked at other people's code, you will know that sinking feeling when you discover 2000 consecutive lines of unindented spaghetti. On the other hand, sometimes you pick up a class library and it just oozes clarity and professionalism.
So the question is - what are the immediate clues that tell you whether a piece of code is a nightmare or a dream? What I'm really hoping for are highly specific answers rather than generalisations - it would be good to be able to use them as a set of explicit tests that we can all apply to our code.
Here's a few of my favourites for starters:
Bad signs:
No indentation or (far worse) wrong indentation.
If, else, or loop blocks that I can't fit on one screen.
Repeated blocks of code that only differ in a couple of lines.
Good Signs:
Member names that fully describe what the member is without needing a comment.
Methods that start with a series of assert statements that document and check the parameters.
Lots of Observer/Listener interfaces.

Recommended Answers

All 2 Replies

Are you talking about the code itself or the clue that a poster is going to be a nightmare to help? In either case, aside from what you mention, a lack of commenting is a good clue. I'm glad you mentioned the variable names. Well defined methods and variable names make it so much easier, as well as PROPER indentation so you can immediately find blocks of code. Any good program of that length should have some comments at the top and/or a README which explains exactly what the program does, what assumptions the programmer makes, what input is needed, the output to expect, etc. Good error messages and good prompts when asking for input are essential. If I make a mistake when entering input, I want the program to catch it, tell me what I did wrong, and give me another chance to enter the correct input.

If your question is dealing with good/bad Daniweb posts and predicting what will be a nightmare to help on, I'd say that displaying effort is the big one. I'm willing to wade through a lot of bad coding practices if I sense effort on the poster's part.

A good thread on a forum has a paragraph or so with an English description of what the problem is, what has been tried, what input is expected, the ACTUAL output, and the DESIRED output, including a SHORT sample input FILE if needed. Preferably it is a short, but COMPLETE program that we can simply copy and paste and compile/run for ourselves. We can't do that, often, if there is a function that is posted that relies on functions or variables that AREN'T posted. At the same time, don't post 30,000 lines of code and a 50,000 line input file. It's vital that people understand that other people are not familiar with their code and they therefore must explain explicitly what their intent is. I think we all fall into that trap (I certainly do). We're familiar with our own code since we wrote it, so it's "obvious" to us and we forget that others can't read our minds.

BAD postings are verbatim copy and pastes of the initial assignment with not a single word from the OP him/herself. That goes straight to the "effort" issue. Salem used to post a link of the good/bad ways to pose a question that I had bookmarked and have subsequently lost. I think it should be pinned to the top of the forums since it's so well written.

Long winded, but that's my two cents.

commented: Here you go - http://www.catb.org/~esr/faqs/smart-questions.html :) +29

Thanks for that input Vernon, I agree with everything you say.
To answer to Q about nightmare code vs nightmare posters: I was thinking only about code; the last thing I wanted to do was to intimidate or embarrass novice posters. It's only normal that beginners will fall into the trap of doing some bad things, and I think it's best to let them do it for a while until they get a bit more familiar with Java itself - avoid information overload. I did hope that if we can document a few favourite good/bad practices that would be useful as people move out of the complete beginner phase.
Having said that - if we did want to document some nightmare poster symptoms, you're list is it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.