in reply to ASCII Battleship Program

A few comments:


A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Replies are listed 'Best First'.
Re^2: ASCII Battleship Program
by perlStuck (Sexton) on Feb 05, 2012 at 13:33 UTC

    I do realize that in the context in which I have used it, protoyping is quite useless. This was at a time when I was rather unsure what prototyping really even was. I simply saw others doing it, and actually thought until recently that it was simply part of the manner in which one defined subroutines. As for the naming of the variables and subroutines, what I was originally planning to do with this was put all the code into one, large program that would allow me to select between other games I played, word processer, possibly an HTML Parser (probably some kind of open-source text-browser already out there) etc. etc. In fact, I was actually intending to make a whole OS-like 'shell' program, for the heck of it. Such aspirations were, naturally, soon abandoned, as such a program was hopelessly out of reach for me. I felt that the naming conventions I used would permit me a broader area of flexibility with which to write other mini-programs in the 'OS'. With local, all I was attempting to do was make it so that subroutines called by other subroutines had access to the same variables that called them. This was before I was particularly well aware of the practice of accepting arguments by use of the variable @_. I felt that such use of local suited my purposes fine, as it would keep all of the variables well within the bound of the battleship program, but would not allow them to seep out into the broader program. My native language is Perl. However, being self-taught, I've developed a style of programming that is probably not only not the greatest, but also simply rather strange looking. But I generally manage to get stuff done, so I'm generally pretty happy with how I code. I do rather fear for whoever's going to have to maintain my code, though . . . .

      That stranger who is going to maintain your code is ... you - about a month from now.

      True laziness is hard work

        Thank you! The book I was using really didn't cover the nuances of Perl, and didn't cover OOP at all. As for perldoc, I'm not really advanced enough to slog through loads of documentation to get what I want. I'm looking forward to reading the both of them.