cfoley's Profile User Rating: -----

Reputation: 2233 Grandmaster
Active Posts:
4,716 (1.65 per day)
11-December 07
Profile Views:
Last Active:
User is offline Today, 02:20 PM

Previous Fields

OS Preference:
Who Cares
Favorite Browser:
Who Cares
Favorite Processor:
Who Cares
Favorite Gaming Platform:
Who Cares
Your Car:
Who Cares
Dream Kudos:
Expert In:

Latest Visitors

Icon   cfoley has not set their status

Posts I've Made

  1. In Topic: Constructors calling each other. Which "direction" is the best

    Posted 5 Oct 2015

    Every class needs one constructor. All code comes at a cost in maintenance so if you're going to add more, you had better have a good reason! Here is one example:

    Whenever I want to write a parser for file format, I always pass a Reader into the constructor:

    public SpecialityReader(Reader in) { = in;

    I used to pass a File object but when I got serious about unit testing I realised that opening files from my test suite was slow and fragile, so I settled on the convention of passing in a reader. Of course, that makes for clunky test code so I sometimes add another constructor so I can just pass a String with the file contents. This isn't a default for me. I only add it when I know I will need it: usually after I already have several tests that need to set up a reader object.

    public SpecialityReader(String fileContents) {
      this(new StringReader(fileContents));

    And you've probably guessed that in my production code I usually read the data out of files so I sometimes add this, but only when it will get used in several places.

    public SpecialityReader(File f) {
      this(new FileReader(f));

    So. please think carefully about which constructors to write. The correct ones will save you time and effort down the line but the wrong ones or superfluous ones can only serve to hinder you. A permutations approach is guaranteed to waste at least the time writing the constructors and the time to scroll past them every time you open the file.
  2. In Topic: Constructors calling each other. Which "direction" is the best

    Posted 5 Oct 2015

    To go back to the original question, the correct answer comes from reflecting on your principles.

    From my experience, customers are happy when my code is bug-free and I can add new features within a day or two of the request. They are sad when it's buggy or it takes forever to add a new feature, even if it runs twice as fast.

    With this in mind, my overriding principal is that the code should be easy to read and maintain. Your mileage may vary and so might mine in the future. If I can do something to make my code more readable and more maintainable then I'll do that. Here is how I would organise your snowman example:

    package quick;
    /** Snowman with 3 snowballs. Diameter in inches. */
    public class Snowman {
    	public static void main(String[] args) {
    		new Snowman(50, 40, 30).print();
    	public static final int DEFAULT_DIAMETER = 25;
    	private int bottomDiameter, middleDiameter, topDiameter;
    	Snowman(int bottomDiameter){
    		this(bottomDiameter, DEFAULT_DIAMETER);
    	Snowman(int bottomDiameter, int middleDiameter){
    		this(bottomDiameter, middleDiameter, DEFAULT_DIAMETER);
    	Snowman(int bottomDiameter, int middleDiameter, int topDiameter){
    		this.bottomDiameter = bottomDiameter; 
    		this.middleDiameter = middleDiameter; 
    		this.topDiameter = topDiameter;
    	void print(){
    	public String toString() {
    		String result = 
    			brackets(topDiameter) + "\n" +
    			brackets(middleDiameter) + "\n" +
    		return result;
    	private String brackets(String s) {
    		reutrn "(" + s + ")";

    Here is why I made these choices. I expect that not everyone will like them:

    1. Moved your comment to be a class-level Javadoc. If you're going to write it, might as well have it in the docs.

    2. Main method at the top. I like my source files to tell the story from top to bottom. If you can understand the file in one scan then I consider this to be a success. Some may object to it being above the instance variables. C'est la vie. In a production system, the main method would be in a class on its own so this would not be an issue.

    3. I felt that reorganising the main method into a one-liner made things clearer.

    4. I left your three instance variables on one line. People tend to like separating them but the only things to change here are the access modifier and the datatype. There is a strong case that if they ever change then they will all change together.

    5. Constructors! Remember I said I like the code to read down the way? Each constructor in the chain calls the constructor directly below it. I've also consolidated all the setting logic into one place. The original set all the variables to the default value and then changed the values if more were passed in. The logic was spread around and the reader had to think carefully to understand what was going on. I strongly considered making all the constructors call the last one directly but decided to go through the chain instead. The reason is that more of the code gets called this way. I feel that the more often code gets called, the quicker bugs will be found. Typically the longer a bug goes undetected, the more expensive it will be to correct down the line. Consider that other code might end up relying on the buggy behaviour at some point down the line. Once that happens it's very difficult to fix the bug!

    6. The print method just prints. It's difficult to write unit tests for methods that print to the console, so I've separated out the string building from the printing. I can test the String building separately.

    7. I've extracted a method to surround the numbers with parentheses. Don't Repeat Yourself, remember. :)

    Of course, if you work for a company with a style guide (or even just conventions that are not formalised) then those rules trump ant of my considerations above.
  3. In Topic: Are Exceptions the preferred practice in the industry?

    Posted 29 Sep 2015

    I also implement a fail-fast policy on most of my code. I do it by letting the exception bubble up the call stack until the thread eventually vomits all over the console.

    In a single-threaded program the overall effect is similar to your boss' code. However, it's more amenable to being incorporated into other code:

    If I parallelise the code, I can give each thread an exception handler so that one error doesn't bring the whole lot down.

    In a user application (either console or gui) I can wrap a function call in an exception handler and provide some sort of error message or ask for information again.
  4. In Topic: Programming languages (Top 10?)

    Posted 12 Sep 2015

    Why are pirates awesome?
  5. In Topic: Programming languages (Top 10?)

    Posted 11 Sep 2015

    9. Smalltalkers love passing messages although nothing of substance was ever said in Smalltalk.

    8. Erlang seemed like a good idea but the processes are just too unreliable.

    7. C is just a Java rip off that doesn't even have objects. This is fixed in C#.

    6. The Rails programming solved the diamond problem with Ruby.

    5. Javascript was a useful prototype before client side scripting was improved by...

    4. HTML5/CSS3 combo: the first Turing complete language that is not a programming language.

    3.5. I forgot BASIC. BASIC can go to 10.

    3. The music industry despises R, which is the native language of pirates.

    2. Lisp is included despite its associated Schemeing and Racketeering.

    1. Piet is a brainfuck but has syntax colouring built in.

My Information

Member Title:
33 years old
April 7, 1982
Forum Leader:
Years Programming:

Contact Information

Click here to e-mail me
Website URL:
Website URL


Page 1 of 1
  1. Photo

    burakaltr Icon

    06 Mar 2013 - 18:18
    Thanks for Your Precious Input. I Found the character counting thing very bedazzling. I have the code to it that I wrote Myself, but it took me Long to find a subtle Algorithm :)
  2. Photo

    cfoley Icon

    18 Oct 2011 - 03:29
    Cheers! The next one is in progress, but I'm having to learn and write some programs first. It's going to take a little time...
  3. Photo

    Dogstopper Icon

    18 Oct 2011 - 03:24
    Nice blog. Can't wait to see more
  4. Photo

    ayaz 786123 Icon

    25 Feb 2011 - 06:49
    have a nice day sir
  5. Photo

    cfoley Icon

    16 Feb 2011 - 17:26
    Oooh thanks! Your comment is the first I heard!
  6. Photo

    m-e-g-a-z Icon

    16 Feb 2011 - 15:34
    Congrats on becoming a Forum Leader! :)
  7. Photo

    Dogstopper Icon

    08 Jan 2011 - 23:49
    "Cabbage" is much better! :D
  8. Photo

    cfoley Icon

    06 Jan 2011 - 16:19
    Cheers dude!
  9. Photo

    Dogstopper Icon

    06 Jan 2011 - 14:36
    "Purple DIC-headed Warrior" doesn't quite apply now that you got the promotion. Well done!
  10. Photo

    DaneAU Icon

    08 Sep 2010 - 09:19
    "cfoley has no profile comments yet. Why not say hello?"
    I don't have many comments either, so i am only doing what the thingy below said to do, hello cfoley and thanks for the thanks :)
Page 1 of 1