My comments on reviewer comments for assignment 1.1

[John Wetherbie]

Hi, all!
I wrote up some responses to the comments I received on assignment 1.1. I am not sure if they will make sense to anyone but Marilyn but if they get some discussion going then maybe it will help other people with the assignment.
I still need to incorporate some of the comments and re-submit!
My code that the comment refers to has a > in front of it.

1) Double check what the class name should be for this assignment.
It appeared to me that "Hundred" was more of a suggestion than a requirement. Of course, in thinking about it (and I really hate to think!), it makes sense that all the assignments should have the same name because then you always type the same thing (or can even automate it). Maybe it should be explicitly stated to call the class "Hundred" in the assignment description.
2) What did you gain by declaring these last two variables?
> private static final String lineBreak = "\n" ;
>
> private static final String space = " " ;
I find it easier to work with constants like these because it cuts down on my typos. Admittedly, these are simple ones but it is an approach that has paid off for me. For a larger program I would probably move these into an interface to be accessed by multiple classes that needed them.
I debated whether to skip them or not. Would you have left them out? If so, why?
3) Rather than "++i" I prefer "i++"
Is this a style issue or a technical issue? In C++ you want to use ++i vs i++ as pointed out in More Effective C++ by Meyers. Is there something similar in Java? If it is style then it should be explicitly called out in the style guide. Otherwise, either style should be OK.
4) Avoid incrementing by anything more than one. Calc the number of iterations ahead of time.

> currentLinePosit += nameLength ;
Don't understand "Calc the number of iterations ahead of time". How would you perform this operation without doing the above? BTW, Section 5.2 of the style guide shows use of +=.
5) currentLinePosit++ ??
> currentLinePosit += 1 ;
Uh, duh! This came about due to reworking something where the original line said something like "currentLinePosit += X". I hang my head in shame.
6) Rather than accumulating the string, why don't you just print it as you go along?
I did this in my original version of the project but thought I was creating too many String objects every time I did System.out.println( string1 + string2 ) ;. So I decided to use the StringBuffer to reduce the number of objects created.
7) Do you really need to instantiate an object? You're introducing OO where I don't see a need for OO.
Do I need to create an object? No, not really. However, it has been my personal experience working with people learning OO and C++/Java that the OO part is the most difficult to learn. People learn the syntax and semantics of Java by writing little classes where the mains do everything and then you ask them to start writing classes (We've got deadlines to meet!) and a lot of them seem to get stuck. Just seems to be a bit of a "hump" there. I wrote an original version with everything in the main and I was just trying to think "OK, I did this but the code is all in the main. What would a (simple) class that took a little more responsibility on itself look like?" So that's why I did it. I may have gone a little overboard�
Could we introduce something like that for extra credit or does the whole class thing come in later?

[Pat Barrett]

Hello John,
I just made it past the first assignment on my third try. I'll toss in my two cents as well.
1) Double check what the class name should be for this assignment.
It appeared to me that "Hundred" was more of a suggestion than a requirement. Of course, in thinking about it (and I really hate to think!), it makes sense that all the assignments should have the same name because then you always type the same thing (or can even automate it). Maybe it should be explicitly stated to call the class "Hundred" in the assignment description.
-- The same thing happened to me. I submitted a version that I had given a different title to (for revision purposes). They don't call it "nitpicking" for nothing.
2) What did you gain by declaring these last two variables?
> private static final String lineBreak = "\n" ;
>
> private static final String space = " " ;
I find it easier to work with constants like these because it cuts down on my typos. Admittedly, these are simple ones but it is an approach that has paid off for me. For a larger program I would probably move these into an interface to be accessed by multiple classes that needed them.
I debated whether to skip them or not. Would you have left them out? If so, why?
---why not just add the " " to your input argument? It would cut down on the clutter in your println's. I like to minimize the variables that I use.

3) Rather than "++i" I prefer "i++"
Is this a style issue or a technical issue? In C++ you want to use ++i vs i++ as pointed out in More Effective C++ by Meyers. Is there something similar in Java? If it is style then it should be explicitly called out in the style guide. Otherwise, either style should be OK.
---- The basic functionality of the pre and post increment operators is the same in Java and C++. Personally, I think that using the post increment operator will result in code that is initially more intuitive and less error prone. Indexing arrays in a loop is an area that the pre-increment operator would require you to either modify the beginning of your loop to something other than zero or make sure that your first element is set to null. It's not always intuitive to remember this.
4) Avoid incrementing by anything more than one. Calc the number of iterations ahead of time.
> currentLinePosit += nameLength ;
Don't understand "Calc the number of iterations ahead of time". How would you perform this operation without doing the above? BTW, Section 5.2 of the style guide shows use of +=.
--- When you consider that you know in advance the number of items you'll be printing (100), the width of the page (80) and the length of the argument you want to print (.length), a little division will get you what you need.
5) currentLinePosit++ ??
> currentLinePosit += 1 ;
Uh, duh! This came about due to reworking something where the original line said something like "currentLinePosit += X". I hang my head in shame.
6) Rather than accumulating the string, why don't you just print it as you go along?
I did this in my original version of the project but thought I was creating too many String objects every time I did System.out.println( string1 + string2 ) ;. So I decided to use the StringBuffer to reduce the number of objects created.
---- You really don't need to create any objects....
7) Do you really need to instantiate an object? You're introducing OO where I don't see a need for OO.
Do I need to create an object? No, not really. However, it has been my personal experience working with people learning OO and C++/Java that the OO part is the most difficult to learn. People learn the syntax and semantics of Java by writing little classes where the mains do everything and then you ask them to start writing classes (We've got deadlines to meet!) and a lot of them seem to get stuck. Just seems to be a bit of a "hump" there. I wrote an original version with everything in the main and I was just trying to think "OK, I did this but the code is all in the main. What would a (simple) class that took a little more responsibility on itself look like?" So that's why I did it. I may have gone a little overboard�
Could we introduce something like that for extra credit or does the whole class thing come in later?
----- Remember, you have to know how to walk before you can run. This is the first assignment on what may turn out to be a very long cattle drive. I introduced OO as well initially, but the nitpicker made me realize that a much simpler solution was available. In the end, I was amazed at the simplicity of the solution. The nitpicker is a stickler for the KISS principle.
Hope this helps.
Pat B.

[John Wetherbie]

Pat,
Thanks for the reply or is it replies? Maybe next time I will post one comment at a time.

---why not just add the " " to your input argument? It would cut down on the clutter in your println's. I like to minimize the variables that I use.

That's a good idea. I was just thinking along another path. I think what it was was that I didn't want to have to go to the next line if the name, without a space on the end, would fit on the line. So I would do the check first and then add the space, or the newline, as needed.

---- The basic functionality of the pre and post increment operators is the same in Java and C++. Personally, I think that using the post increment operator will result in code that is initially more intuitive and less error prone. Indexing arrays in a loop is an area that the pre-increment operator would require you to either modify the beginning of your loop to something other than zero or make sure that your first element is set to null. It's not always intuitive to remember this.

Not following you here. Whether you use pre or postfix notation to increment does not cause you to write
for(int i=0;i<X;i++)>
vs
for(int i=1;i<X;++i)>
So, if I wrote:

for( int i=0 ; i < 5 ; ++i)
{
    System.out.println(i) ;
}

I would get:
0
1
2
3
4

6) Rather than accumulating the string, why don't you just print it as you go along?
I did this in my original version of the project but thought I was creating too many String objects every time I did System.out.println( string1 + string2 ) ;. So I decided to use the StringBuffer to reduce the number of objects created.
---- You really don't need to create any objects....

I could create two Strings - one that is the name with a space and one that is the name with a newline - and just print these. That would certainly be one alternative.

John

[Pat Barrett]

You're right on the post increment thing. I don't follow myself either. I've always used post-increment and rarely use pre-increment so I guess I'm pre-disposed to think that post is more reader friendly. It must be a style thing...
Pat B.

[Rachel Hirstwood]

In the question for this assignment there is a subtle hint about how simple it should be - the number of lines of code required to get top marks. Surely creating all those objects and increments etc will bulk your code out to 50 or more lines? The assinment suggested nearer 28.

[John Wetherbie]

Rachel,
I created seven objects in this version of the assignment and they were all one-liners, so it added some but not that much. I will give the assignment another go and see if I can cut it down.
I'd be careful about thinking that few or fewer lines of code always means simple or simpler. For this assignment it most likely does but this is not always the case. It may be worth it to have additional code that makes your software more flexible in certain areas so through the lifetime of the system it is easier to adapt it to changes in the environment (including requirements).
John

[John Wetherbie]

Pat,
I was a postfix guy (in C++) until I read More Effective C++ by Meyers. It talks about how prefix is more efficient for user-defined types and that for primitives it is a wash. So instead of using one style for primitives and one for user-defines I just used prefix. Now its just a habit.
John

[Marilyn de Queiroz]

JW>It appeared to me that "Hundred" was more of a suggestion than a requirement. ... Maybe it should be explicitly stated to call the class "Hundred" in the assignment description.

MQ>
"In other words, I want to type

java Hundred Gertrude"

JW> I find it easier to work with constants like these because it cuts down on my typos. Admittedly, these are simple ones but it is an approach that has paid off for me. For a larger program I would probably move these into an interface to be accessed by multiple classes that needed them.

MQ> Using constants can be good. However, I would be more apt to make a typo on 'space' than on " ". The time will come when the assignment will utilize this approach. However, this is not that assignment.
JW>Regarding "++i" vs "i++: Is this a style issue or a technical issue?

MQ>This is a preference.
JW>Don't understand "Calc the number of iterations ahead of time". How would you perform this operation without doing the above?
MQ>What Pat said
JW>BTW, Section 5.2 of the style guide shows use of +=.
MQ>+= yes, definitely useful.
JW>I did this in my original version of the project but thought I was creating too many String objects every time I did System.out.println( string1 + string2 ) ;.

MQ>Good observation.

So I decided to use the StringBuffer to reduce the number of objects created.

MQ>How about System.out.print( string ); It's the same string each time.
JW>Do I need to create an object? No, not really. ... Could we introduce something like that for extra credit or does the whole class thing come in later?
MQ>OO is introduced in class 3

[John Wetherbie]

Thanks, Marilyn.
I sent in take 2 of the assignment. I hope I don't have as many nits to pick this time.
John

[paul wheaton]

Assignment 1.1 is the one where everybody gets beaten into submission.
To go over your points:
1) Marilyn, can you add this to the common nits page?
2) Readability is the most important thing. And Marilyn is actually reading your code. So who better to be the judge of what is readable? To top it off, Marilyn is now a professional code reader! In this particular case, if Marilyn sees lineBreak, she has to look up to see what that means. If she sees "\n", she knows.
3) ++i is faster in C, C++ and, if I remember correctly, Pascal. This is Java. i++ and ++i are equally fast (as Peter Haggar proved to me a year ago). I find that i++ is more readable and more consistant with the rest of the language. And the style guide prevents any use of a case where ++i could make a difference. Therefore, I suggest post increment/decrement at all times.
7) OOP is a great thing. But that doesn't mean it's the best solution for all problems. (when you have a hammer, every problem looks like a nail?) The important thing is good, simple, clean, readable code. In this case, adding object stuff just complicates things. Marilyn, maybe this can go under "KISS" in the common nits page.

[John Wetherbie]

Paul,
Thanks for providing the info on prefix & postfix performance. It doesn't seem to matter which one you use.
However, if you wish people to use one or the other for readability or style reasons it should be documented in the style guide. Can someone add this to it?
Thanks,
John

[paul wheaton]

There are a lot of things I prefer that are not added to the style guide. If the style guide gets too big, people won't read it.

[Norman Leach]

Originally posted by Paul Wheaton:
There are a lot of things I prefer that are not added to the style guide. If the style guide gets too big, people won't read it.

style guide? what style guide? :-)

[Marilyn de Queiroz]

About the cattle drive, the Style Guide, the Common mistakes page, and the hot links on the assignment page(s) may save lots of time and effort.

[This message has been edited by Marilyn deQueiroz (edited January 19, 2001).]

[John Wetherbie]

I get to move on to assignment 1.2 now!
The instructor solution just made me think "Wow, I wish I had thought of that!"
John

[Elisabeth Van]

I've been puttering around with Java for about a year now, and pretty much thought I'd blow right through assignment 1.1...well, I had my share of nits getting picked, and I sure do appreciate it. This sure is a great help to me to have someone to review my code and point out things like optimizing concatenations. Learning all sorts of stuff here...Keep on Nitpicking!