assingment, styling, refining, and error checking guidelines. please

[Stan Austin]

so I am new to Java (a long 6 weeks it has been)
Once again thank you guys for all your help this far, I have I feeling you're going to grow bored of me soon. However hopefully I will become adept enough to help others as you have helped me in the not to distant future.
and on that note I have written my 1st program for submission, the brief asks a few further things and I was hoping for some addition guidance.

Errors
your program should compile with 0 errors.
It should not throw any exemptions except in the case of command line parameter being an int but is not, in this case it should throw the default parsing exception (not sure on this)

Styling
consistent and reasonable indentation and spacing (what are the most basic fundamentals of this)

Refinement
Use of final at the end of your program should be such no variable declaration a final can be added without causing a compilation error (unsure what this means, what is a final?)
Locality of Variables, (the program is theoretically several programs sewn together so different inputs such as 1 string 1 int 2 ints carry out different actions do these all need a new variable each time? does every for loop need a new variable if they are for the same purpose and not nested?)
Clean-up and remove all Additonal "test"outputs and all comments

finally I know this may be construed as cheating but does NetBeans IDE have any tools to help with formatting or cleaning up, to make my first assignment really pop (after i have been through manually)

Thanks again guys really looking forward to polishing and making my program look gorgeous!!

[Knute Snortum]

Stan Austin wrote:
Errors
your program should compile with 0 errors.
It should not throw any exemptions except in the case of command line parameter being an int but is not, in this case it should throw the default parsing exception (not sure on this)

You probably have a line of code that looks like this:

int someInt = Integer.parseInt(args[0]);

The method parseInt() will throw an exception if args[0] is not an integer.  This is normal and you don't have to do anything.

Styling
consistent and reasonable indentation and spacing (what are the most basic fundamentals of this)
...
does NetBeans IDE have any tools to help with formatting or cleaning up, to make my first assignment really pop (after i have been through manually)

In the NetBeans and Eclipse IDEs, the key combination Ctrl-Shift-F will format your code.  This will show you a good, consistent formatting that you should be able to type in manually.  Look here for one way to format your code manually.

Refinement
Use of final at the end of your program should be such no variable declaration a final can be added without causing a compilation error (unsure what this means, what is a final?)

"final" is a keyword in Java that when applied to variable declarations means, basically, that the value of the variable will not change after initialization.  A lot of people feel you should mark as many variables final as possible.  It would look like this:

private final int number = 100;
// ...or...
private void foo(final int number) {

Post your code here when you're done, and UseCodeTags (that's a link).

[Junilu Lacar]

Stan Austin wrote:
finally I know this may be construed as cheating but does NetBeans IDE have any tools to help with formatting or cleaning up, to make my first assignment really pop (after i have been through manually)

Why would it be cheating? Does a farmer "cheat" when he uses a tractor instead of an ox to plow his field? Or a carpenter a hammer instead of a rock? Use the tools that are at your disposal to make your job easier and so you can focus your energy and attention on other things.

[Stan Austin]

Hi Knute,
thanks for the tips the format tool made a huge difference, I don't think I could make it that tidy myself lol, hopefully i wont become lazy so early on :/

please see the code below, also i had a some issues when formatting the for loops getting really odd results, the differences between x++, ++xand x = x+1 actually gave different results ?? any reason why?

package cases;

public class Cases {

    public static void main(String[] args) {
        final int argleng = args.length;
        if (argleng == 0) {
            System.out.println("Hello World!");
        }
        if (argleng == 1) {
            final String x = (args[0]);
            System.out.println("Hello World! " + x);
        }
        if (argleng == 2) {
            final String x = (args[0]);
            final String y = (args[1]);
            System.out.print("Hello World! " + x);
            System.out.println(" and " + y);
        }
        if (argleng == 3) {
            final int a = Integer.parseInt(args[0]);
            final int b = Integer.parseInt(args[1]);
            final int c = Integer.parseInt(args[2]);
            if (a == 0 || b == 0 || c == 0) {
                System.out.println("True");
            } else if (a + b == 0 || a + c == 0 || b + c == 0) {
                System.out.println("True");
            } else if (a + b + c == 0) {
                System.out.println("True");
            } else {
                System.out.println("False");
            }
        }
        if (argleng == 4) {
            int a = Integer.parseInt(args[0]);
            int b = Integer.parseInt(args[1]);
            int c = Integer.parseInt(args[2]);
            int d = Integer.parseInt(args[3]);
            int t;
            if (a > b) {
                t = b;
                b = a;
                a = t;
            } else {
            }
            if (b > c) {
                t = c;
                c = b;
                b = t;
            }
            if (c > d) {
                t = d;
                d = c;
                c = t;
            }
            if (a > b) {
                t = b;
                b = a;
                a = t;
            }
            if (b > c) {
                t = c;
                c = b;
                b = t;
            }
            if (a > b) {
                t = b;
                b = a;
                a = t;
            }
            System.out.println(a + " " + b + " " + c + " " + d);
        }
        if (argleng >= 5) {
            int[] array2;
            array2 = new int[argleng];
            int b = 0;
            for (int i = 0; i < argleng; ++i) {
                array2[i] = Integer.parseInt(args[b]);
                ++b;
            }
            if (array2[0] % 2 == 0) {
                int f = 0;
                for (int i = 0; i < argleng; i = i + 2) {
                    f = f + array2[i];
                }
                for (int i = 1; i < argleng; i = i + 2) {
                    f = f - array2[i];
                }
                System.out.println(f);
            }
            if (array2[0] % 2 != 0) {
                int f = 0;
                for (int i = 0; i < argleng; i = i + 2) {
                    f = f - array2[i];
                }
                for (int i = 1; i < argleng; i = i + 2) {
                    f = f + array2[i];
                }
                System.out.println(f);
            }

        }

    }
}

[Junilu Lacar]

If you're serious about not being lazy and really wanting to develop a good style, then consider names like "argleng" as being counter to those goals. A name like "argleng" is just about the laziest kind of choice and poorest kind of style you can have.

What do you gain by using a name like that? A few less keystrokes? And is that worth the sad lack of clarity, readability, and expressiveness in your program? If you had used a name like "numberOfParameters" or "parameterCount", or if you are really that lazy to type, "paramCount",  that would have made it clearer that your intent was to see how many parameters were passed to the program. On the other hand, "argleng" is just an incoherent mumbling of the expression args.length.

If you use any modern IDE that has an autocomplete feature, the "I don't want to type so much" defense goes out the window because you hardly ever have to type the whole name yourself. In Eclipse, I just hit Ctrl+space after typing one or two characters of a name and the IDE will give me a list of matching names to choose from. So being a lazy typist is not a valid reason to use awful names like argleng.

[Knute Snortum]

i had a some issues when formatting the for loops getting really odd results, the differences between x++, ++x and x = x+1 actually gave different results ?? any reason why?  

All three are related, but not the same.

x++ means use the value of the variable, then increment it.  So in the code:

int x = 0;
int a = b[x++]; // a == b[0]
// Here x == 1

... but ++x means increment, then use the new value of the variable, so:

int x = 0;
int a = b[++x]; // a == b[1]
// here x == 1

[Stan Austin]

Junilu Lacar wrote:If you're serious about not being lazy and really wanting to develop a good style, then consider names like "argleng" as being counter to those goals. A name like "argleng" is just about the laziest kind of choice and poorest kind of style you can have.

Not going to lie, feeling a little offended by the wording of your comment, but I take you point, and criticism accepted.
so far we have only actually used letters a,b,c, etc. I in all honesty felt argleng, was quite descriptive, and my logic for not writing "NumberOfArguments" or "ArgumentCount", (didn't know a parameter was the same thing) was in fact due to space,
we have been told about the importance of vertical and horizontal space and the fact it is a commodity, so we need to keep variable names short and concise.
I appreciate your input and don't dispute it, however since it is quite contrary to what i have been told by the one other person with input on the matter I would appreciate some reference on choice of variable names or input from the wider community, and will take that forward with me as a convention.
Thank you for your input though.

[Junilu Lacar]

Stan Austin wrote:

Junilu Lacar wrote:If you're serious about not being lazy and really wanting to develop a good style, then consider names like "argleng" as being counter to those goals. A name like "argleng" is just about the laziest kind of choice and poorest kind of style you can have.

Not going to lie, feeling a little offended by the wording of your comment, but I take you point, and criticism accepted.

I'm sorry if it seemed a bit harsh, it wasn't meant to be anything personal. It's natural for a programmer to attach a bit of themselves to their code. But there's this concept called egoless programming and that's really the context in which I hope you take the comments. The critique is at the code, not the author. Thanks for having an open mind though. Just so you know, this is the kind of thing that I tell all the programmers I work with when they do the same kind of things; and because we have a good rapport, I can often get away with saying things that would come across as even more offensive but it's all in the spirit of egoless programming. It's about getting better, not putting anyone down.

[Junilu Lacar]

Stan Austin wrote:in all honesty felt argleng, was quite descriptive, and my logic for not writing "NumberOfArguments" or "ArgumentCount", (didn't know a parameter was the same thing) was in fact due to space,
we have been told about the importance of vertical and horizontal space and the fact it is a commodity, so we need to keep variable names short and concise.
I appreciate your input and don't dispute it, however since it is quite contrary to what i have been told by the one other person with input on the matter I would appreciate some reference on choice of variable names or input from the wider community, and will take that forward with me as a convention.
Thank you for your input though.

Read Robert Martin's book, Clean Code. The second chapter is all about good names. That's what I encourage all programmers to use as their guideline. Vertical and horizontal space being a commodity is such a 1990s way of thinking.

You might actually be able to find something by googling for clean code good names

[Junilu Lacar]

Stan Austin wrote:but I take you point, and criticism accepted.
...
Thank you for your input though.

Thank you again for taking my tactless comment in stride. I recognize that the way I say things can rub people the wrong way and I'll make some adjustments going forward. Have a cow on me.

Best regards

[Stan Austin]

Junilu Lacar wrote:
Thank you again for taking my tactless comment in stride. I recognise that the way I say things can rub people the wrong way and I'll make some adjustments going forward. Have a cow on me.

Best regards

Junilu, Thank you very much for the advice, it is really appreciated, and don't worry I see what you mean regarding ego-less programming. I suppose this is a very important mindset to have.
It was that after spending over 30 hours on this, the longest program I have written so far (and the most complex) and really throwing myself into getting everything just right, "lazy" pushed a button.
However, I have my first prestigious COW, so that more than makes up for it, Thank you.
I will make some final alterations to my code, and get the names just so!

Thanks

[Junilu Lacar]

Here's another good one from Uncle Bob's Clean Code book:

A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.