Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I had asked this question on Stackoverflow, and before it got booed off, I received the helpful suggestion from Péter Török that this might be a better place to post it.

I've been programming in Java for a few years. I've often discussed design decisions with colleagues on the basis of what constitutes 'good style'. Indeed, there are a number of StackOverflow questions/answers that discuss a design on the basis of whether something is 'good style'.

But what makes 'good style'? Like many things, I know it when I see it... but I wanted to have better idea than just my conscience saying that this design doesn't feel right.

What are the things you think about in order to produce good, well designed code?

(I acknowledge that this is somewhat subjective, as what is 'good style' will depend on the task at hand). (Also, I should add that I'm not interested in team styles - e.g. "we use indents of 2 spaces rather than 4"..., and I'm not interested in the Java code conventions.)

Edit: thanks for all the good answers/comments so far. I'm especially keen for answers that would help codify those things that make a programmer's conscience (and possibly stomach) wrench?

share|improve this question

closed as too broad by gnat, GlenH7, Bart van Ingen Schenau, MichaelT, Robert Harvey Dec 2 '13 at 18:23

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Among many other things listed here, I would definitely make sure to simply state that computers can compile code in just about any way you write it, but ultimately, code needs to be human readable. Comment like crazy! A good test I like to use: could a person read only my comments to learn what the code does, what it's inputs and outputs should be, and the algorithm(s) used to do it? –  Brian Aug 22 '11 at 16:42
1  
@brian, make your code explain how. Leave actual comments to explain why. In other words, do not comment like crazy (in the general case) –  user1249 Aug 22 '11 at 17:03
4  
Brian: That technique is definitely not considered good practice. Common good practice is to aim to make your code as self-documenting as possible (with clear variable names and function cohesion), with comments to explain the "why" and not the "how". Comments that explain every little detail are generally considered distracting and often dangerous, since people are less likely to maintain the comments than the code. –  Casey Patton Aug 22 '11 at 17:10
1  
@Brian: Your last statement says it all. The code should be readable. Comments get stale. Code never does. If you feel the need for comments, refactor until the code is so clear that comments would just be repeating what the code says. The only good comment is one that says why the code works a particular way--like to avoid a bug in a third party library--so that someone doesn't go back and change it to something that won't work for a reason that isn't immediately apparent. –  Ryan Stewart Aug 23 '11 at 14:21
2  
I've officially been humbled. Sorry @amaidment. I guess need to research good coding standards when it comes to comments. –  Brian Aug 23 '11 at 15:35

4 Answers 4

A few brief points:

share|improve this answer
3  
+1. Perhaps most critical: minimize duplicated code. If you are tempted to cut and paste more than a few tokens, you need to extract a function. Even if the function is a single line of code. –  kevin cline Aug 22 '11 at 16:19
4  
On duplicated code, I take the following stance. Cut and paste = okay. That's just moving code (assuming you use paste once). Copy and paste = horrible. If you just remove the copy button from your vocabulary, you're more likely to do the right thing. –  jsternberg Aug 22 '11 at 16:22
    
@jsternberg: +1 for cut/copy distinction, but I notice that a lot of people say "cut/paste" when they mean "copy/paste". I don't know how the distinction was lost. –  Ryan Stewart Aug 22 '11 at 16:41
5  
Do not repeat yourself. Do not repeat yourself. Do not repeat yourself. –  configurator Aug 22 '11 at 16:53
1  
@configurator, you smell a little bit funny... –  user1249 Aug 22 '11 at 18:23

Adding to Ryan's list:

  • Follow the SOLID principles
  • Ensure that your code doesn't have too much cyclic complexity
  • Test Driven Java is always a good thing
  • If you have a xFactoryFactory class, you're doing it wrong :-)
  • Given the open source libraries in the Java ecosystem, re-inventing the wheel is bad style
  • Use Joda time for date and time

I'll stop there.

share|improve this answer
2  
But what about the HammerFactoryFactoryFactory class? ;-) –  Wayne M Aug 22 '11 at 17:30
    
@Wayne, Factories are an indication that some decisions need to be delayed, and FactoryFactoryFactories indicate that there is a decision that really needed to be made at runtime but couldn't. –  user1249 Aug 22 '11 at 18:25
    
I know, I was being sarcastic and referencing that article about why then-J2EE was overly complex, with HammerFactories and HammerFactoryFactories and I think HammerFactoryFactoryFactories. :) –  Wayne M Aug 22 '11 at 18:29
    
@Martijn - thanks for the SOLID link; I've not come across that before. You suggest using JodaTime; is this just an (appropriate) aversion to the Java Calendar/Date classes? What about JSR310 (the successor to JodaTime)? –  amaidment Aug 23 '11 at 6:48
    
JSR-310 will hopefully make it into Java 8 (there's a bunch of us gearing up to try and help make that happen, contact me if you want to get involved). In the mean time, Joda time is the defacto std for dealing with date and time in Java. There's so many things wrong with Java's Date and Calendar system that I don't even know where to start ;-). The killer is that Dates are mutable and that there's no concept of an instant or period or... nope I'm gonna stop there :-). –  Martijn Verburg Aug 23 '11 at 9:47

Whilst appreciative of others' answers, I thought it only fair to share a few of the things I think about when trying to write good code:

  • what needs to know about this class/method/variable? i.e. where should this knowledge live?

  • how might this code affect the memory/performance of my application? (I acknowledge that 'premature optimisation is the root of all evil'; so I'm not suggesting spending lots of time optimising, but rather a consciousness whilst initially writing my code.)

  • is it clear (from the code, and code structures) what this does? (I try to follow the maxim: "Strive not to make it possible for people to understand, strive to make it impossible for people to misunderstand".)

share|improve this answer

Read the String and ArrayList class for excellent examples of proper Java programming. But they are highly concise, almost C style, which isn't necessarily best for maintainable code w/ minimal java docs. The common practice at my shop is no comments, so I try to comment by code by using verbose camelCase var names and excessive use of newlines to delimit one line of thought from another. I still debate using tabs to separate vars from their values. Tabs can enhance readability, IMO, but only when done minimally and it's very subjective. I find it's really about the audience. There's no best answer here.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.