Stretch and Sketch Before You Leap (into coding)
"Look before you leap" is a common alliterative warning (WaZit?) about diving blindfolded into a strange pool or any other unmapped situation (e.g., a coding project).
Yet so many beginner programmers try hammer some code onto a blank page, thinking that doing it from "scratch" is the best way.
They're wrong. It's the worst way.
See gQAB ::: Plan before you run
(Note: QAB stands for Query ABout. The "g" prefix means via google)
See also: Reasons You Should Plan Your Python Code Before You Write It by dts)
See gQAB ::: Plan before you run
(Note: QAB stands for Query ABout. The "g" prefix means via google)
See also: Reasons You Should Plan Your Python Code Before You Write It by dts)
No general goes into battle without first having mapped out the terrain, without first having studied the enemy and having analyzed the various obstacles that may foil the campaign (e.g., will the Russian winter defeat Napoleon's / Hitler's troops?).
So how does that apply to a new coding project?
One Python Vlogger (Wu --here: How to build understandable programs) gives an example based of designing a Tic-Tac-Toe game to be played by two players (url for image to right is here) (see also G4G here)
Wu (above) explains many of the considerations that should go into the pre-coding analysis including (1) defining the field of play (e.g., 3x3 grid), (2) defining what constitutes a valid move --and by whom-- at each phase of the game, (3) begin only with pseudocode, (4) OOP state machines: (examples= Can the game grid be an object with attributes such as: number of rows /columns, number of occupied/ empty cells, type of object in each filled cell? Methods can include detecting that game is over due to win or tie? Can each player be an object?)
Similar pre-analysis can apply to a chess game (url for image at right)
TO BE CONTINUED
MORE TO EXPLORE
xyzxyz
Comments
Post a Comment