12. Bad Aim



When I enter row & col values inside the range such as 3 & 3, my code passes.
When I enter outside the range, such as 6 & 6, I get fault:

Traceback (most recent call last):
File "python", line 35, in
IndexError: list index out of range

MY CODE (I haven't added comments yet. So professionally, I'd grade this as bad programming.):

from random import randint

board = []

for x in range(0, 5):
    board.append(["O"] * 5)

def print_board(board):
    for row in board:
        print " ".join(row)


def random_row(board):
    return randint(0, len(board) - 1)

def random_col(board):
    return randint(0, len(board[0]) - 1)

ship_row = random_row(board)
ship_col = random_col(board)
guess_row = int(raw_input("Guess Row:"))
guess_col = int(raw_input("Guess Col:"))

print ship_row
print ship_col

# Write your code below!
if guess_row == ship_row and guess_col == ship_col:
    print "Congratulations! You sank my battleship!"
    print "You missed my battleship!"
#        guess_row = "X"
#        guess_col = "X"
    board[guess_row][guess_col]="X"   #copied fm Q/A
    print print_board(board)          #copied fm Q/A


if guess_row not in range(5) or \
guess_col not in range(5):
print "Oops, that's not even in the ocean."
else :
print "You missed my battleship"


A program this small is self documenting. In other words, we can read the code and see what it does. No need to comment it.

To avoid the error you are raising, reverse the test condition order and test the range first, then check if the coordinate has been guessed already.

if # is a hit:

elif # is in range:

elif # is a previous guess:

else: # it's a miss


Thanks for the comment. It's clear & concise. Good job! And I got the code working before you wrote.

Regarding your feelings about no need to comment short code elements, It's a habit for me. I offer a thought you may consider from my experience.

In my years supporting the military and combat, I realized the troops under pressure don't have time to analyze. So in everything I designed in hardware and explained in mechanization reports or coded and commented in software, I worked to insure I was clear and concise. It's part of me.

Yes this code is terse, but I bet I'll come back to it in a couple weeks and ask myself, what in the world was I writing? It's been a while since I coded in C, so Python is a fun review now.


I don't disagree with you. When others are going to be working with our code, or we will be coming back to it in six months time, documentation is very important, especially when there are lots of moving parts. We do not need to document the obvious, though. That only muddies the waters of readability.

Consider also that if we write as many pure functions as possible, they will be easy to document, if necessary since they are totally self contained and only work with data that is handed in to them. Pure functions never reach outside for data.

On the whole, you get no argument from me concerning the value of good documentation, but for our purposes here, given there are instructions in every page, it is not necessary and may only add to the confusion while we are learning (if we are not exactly clear on the concept we are attempting to document).

At any length, most of the long term 'helpers' here are very familiar with the bulk of problems on this site, so we don't need documentation in order to be able to help. The discussion helps to fill that void.

Python offers a wonderful tool for documentation, the docstring

""" This is a Python docstring """

''' and technically, so is this (I think) '''

When all the documentation is at the top 
of each section of code it is easier to take 
it all in at once, without having it sprinkled
throughout the code, itself.

# code section