Gabriel Golcher

CM 632

CSSE-375

May 5, 2005

HW8

 

Program Header Format

Certainly what we have been taught in the initial Java classes is what applies here. I like to make individual public classes and generally make very descriptive names (i.e. TicTacToePanel or ComputerClient)

Identifiers � general guidelines

Verbose naming is definitely my style. Since commenting is not my strong-suit, for code readability, I seek to make my identifiers verbose and descriptive. For me, whether I start the first letter as upper-case or lower-case it doesn�t matter.

Identifiers � good examples

private boolean receivedHeight

String connectingClientName

public Boolean checkVictoryConditions()

Identifiers � bad examples

private Boolean recvHt

String client

public Boolean checkWin()

Comments � general guidelines

Commenting is not something I do often, although I recognize its importance and acknowledge I must do it more. That is exactly why lately I�ve tried to comment my code more than I have done in the past. For me comments need to be descriptive. Some people care about length, but for me that does not matter. As long as the explanation is clear, it�s fine with me. I generally tend to write them longer than other people to ensure they are clear. Also, comments inside a method are always welcome.

Comments � good examples

/**

�* This method checks whether a given

�* computer player�s turn is coming up.

�* It queries the server after it is notified

�* that a card has been played. If it is the

�* computer�s turn, it goes.

�**/

 

//Check to ensure that a string of adequate length has been passed

 

//Call the panel so that an error pop-up box will be displayed.

Comments � bad examples

/**

�* Check if it is the computer�s turn

�**/

 

//string correct?

 

//Create pop-up here

Blank lines � when to use

Blank lines are something I generally do not use, but also acknowledge that they can increase readability as long as they separate groups of LOC that share a common idea or purpose. Random blank lines or putting a blank line after every line should be avoided like the plague.

Blank lines � good examples

public int index;

public String identifierName;

 

private Boolean checkForParent;

private String nameBuffer;

Indenting � general guidelines

Indentation should be used whenever an if or a while or any other sort of conditional or anything else that encapsulates in brackets is used. Thus, if code is inside brackets, indent, otherwise don�t.

Indenting � good examples

for (int i = 0 ; i < 10 ; i++) {

this.checkPlaced(board[i]);

}

 

if (e.getSource().equals(exitButton)) {

quitGame = true;

} else {

player2.setTurn();

}

Capitalization � general guidelines

Capitalization should be used whenever a new word is used in an identifier. I do this all the time. For final variables, I still follow this style because I do not like how a variable name all in capital letters looks.

Capitalization � good examples

public JButton acceptButton;

 

private final int maximumChips;

Selection statements � general guidelines

I try to use it-else if-else cases as much as possible. Case statements and other constructs tend to make things more complicated and harder to understand. If statements are much simpler to read.

Something I always do and believe is good style is to have one-line ifs enclosed in brackets and indented on the next line. I do not like using the short form of ifs with a question mark. I do not stress having empty elses and generally do not put them in.

Selection statements � good examples

if (gameIsStarted) {

player1.turn� = true;

} else {

game.resetBoard();

game.restartPlayerPositions();

}

Selection statements � bad examples

if (gameIsStarted) player1.turn� = true;

else {

game.resetBoard();

game.restartPlayerPositions();

}

Loops � general guidelines

Loops are generally for-loops and while/do-while loops. These tend to be the easiest for me to understand and thus are pretty much the only ones I use. I do not have many rules concerning these, but I do believe that infinite loops should not be the empty for-loop but the while loop. Also, I have absolutely no qualms about using breaks. I rarely used named loops, although I�ve been known to use them on occasion. I have nothing against them.

Loops � good examples

for ( ; ; ) {

client.checkConnection();

if (disconnect)

return;

}

Loops � bad examples

while (true) {

client.checkConnection();

if (disconnect) {

break;

}

}

Return statements � general guidelines

Return statements should only be used to return values to a calling method, never to exit out of the method. Otherwise, things become very unreadable.

Return statements� � good examples

public string getName() {

return this.name;

}

More on your general philosophy of coding style

What I have described is pretty much an accurate portrayal of what my general philosophy of coding is. For me, expediency is certainly not the biggest priority and if my code takes up 10 more LOC than someone else�s because it has longer variable names and more code comments, that�s fine. For me how readable and easy to understand is certainly a top priority.

At the same time, I try to reuse code as much as possible, because it helps me to concentrate on what is left to be written and not in �reinventing the wheel�,

Finally, when I code, I tend to write the error messages and the bad input first rather than the correct functionality, because that way, once all of the program certainly handles the errors, I can concentrate on making the functionality as efficient and powerful without worrying about missing some minor check here or there.