Junilu Lacar wrote:The name FileProcessor is also vague whereas the JavaDocs are very specific. If the JavaDocs fully explain the reason for this class' existence, then maybe you can find a name that better reflects that purpose.
Junilu Lacar wrote:
feel free to tear it apart
Ok...
A program should tell a story. This program doesn't tell its story very well. It starts out being very vague about what it's doing by creating a FileProcessor object and then calling that object's copyFile() method. Nothing else in that code gives the reader any kind of context on what they should expect, except the error handling boilerplate around the call to copyFile(). What file is being copied? Where is it getting copied to? The code is very mysterious-looking.
Junilu Lacar wrote:
Pablo Aguirre wrote:I'm replicating a question I posted on stackexchange so here's the link if you want to check out some opinions.
Thanks for informing people that you've posted the same question elsewhere. You missed adding the link though so here's the one I found: https://codereview.stackexchange.com/questions/243005/architecture-and-error-handling-in-simple-java-program
Zachary Griggs wrote:
I don't think countCommas should declare that it throws an IOException
You catch IOException here. You could also move the lines above (that may throw IOException) into this try block.
So it can't throw any IOException.
Junilu Lacar wrote:
Does this clear up some things for you?
Junilu Lacar wrote:
Pablo Aguirre wrote:I'm still a bit confused with the names of the variables. ... I'm assuming the y,x variables in the if statement are the ones in the game object, not the new ones created to run the loop?
If you're referring to the y and x here:
for (int y = ... ) {
for (int x = ... ) {
then yes, they are the ones referred to in the if-statements. The gameObject x and y fields are qualified: gameObject.x and gameObject.y.
Shouldn't they have a different name to make it easier to visualize? (a,b) or whatever. Or what am I missing? Again thanks a lot for the invaluable replies.
They could have different names but I doubt (a, b) would make their intent any clearer. 'neighborX' and 'neighborY' maybe but that's a little wordy. In this case, I don't actually mind y and x that much.
I could suggest at least one different way that is more object-oriented but that would take us a whole 'nother path that you might not be ready to go down right now.
Tim Holloway wrote:OK. The object is to create a List og GameObject's that are adjacent to a specified GameObject. This is done by scanning the following potential matrix, which is overlaid on the board matrix:
Note that the center cell is omitted, since that's where the reference GameObject itself lies.
We increment the x and y co-ordinates from relative -1 to relative +1, indexing the x co-ordinate the fastest. Or, in other words, scan by row, then column going left-to-right and top-to-bottom.
Hower, the gameboard is of finite dimensions, so co-ordinate positions that fall off the edge of the board (board co-ordinates of less than 0 or more than the board width and height) are ignored, since they don't exist and would throw an ArrayIndexException if you tried to use them.
Given those constraints, the eligible cells are each checked for the presence of another GameObject, and if present, that GameObject is added to the returned list. If there are no adjacent objects, an empty list will be returned.
Junilu Lacar wrote:It looks like the code assumes that all cells on the gameField have gameObjects in them. Maybe an empty cell is also represented by a special kind of GameObject instance.